👋 We've unified all of GitHub's product documentation in one place! Check out the content for REST API, GraphQL API, and Developers. Learn more on the GitHub blog.


我们经常发布文档更新,此页面的翻译可能仍在进行中。有关最新信息,请访问英文文档。如果此页面上的翻译有问题,请告诉我们
文章版本: GitHub.com

关于拉取请求合并

您可以通过将所有提交保留在功能分支中、将所有提交压缩到一个提交中,或者将个别提交从“头部分支”变基为“基本”分支,以 合并拉取请求

本文内容

在 GitHub 上的拉请求上中单击默认的 Merge pull request(合并拉请求)选项时,来自功能分支的所有提交都会在合并提交中添加到基础分支。 拉取请求使用 --no-ff 选项合并。

要合并拉取请求,必须在仓库中拥有写入权限

standard-merge-commit-diagram

压缩与合并拉取请求提交

对 GitHub 上的拉取请求选择 Squash and merge(压缩并合并)选项时,拉取请求的提交会压缩为单一提交。 不是从主题分支查看所有贡献者的个别提交,而是所有提交合并成一个提交并合并到默认分支。 压缩了提交的拉取请求使用快进选项合并。

要压缩并合并拉取请求,必须在仓库中拥有写入权限,并且仓库必须允许压缩合并

commit-squashing-diagram

您可以使用压缩并合并在仓库中创建更简化的 Git 历史记录。 在功能分支上工作时,提交正在进行的工作会有帮助,但它们不一定必须留在 Git 历史记录中。 如果在合并到默认分支时将这些提交压缩到一个提交中,您可以保留原来的更改并清除 Git 历史记录。

Merge message for a squash merge

When you squash and merge, GitHub generates a commit message which you can change if you want to. The message default depends on whether the pull request contains multiple commits or just one.

Number of commits摘要描述
One commitThe title of the commit message for the single commit, followed by the pull request numberThe body text of the commit message for the single commit
More than one commitThe pull request title, followed by the pull request numberA list of the commit messages for all of the squashed commits, in date order

Squashing and merging a long-running branch

If you plan to continue work on the head branch of a pull request after the pull request is merged, we recommend you don't squash and merge the pull request.

When you create a pull request, GitHub identifies the most recent commit that is on both the head branch and the base branch: the common ancestor commit. When you squash and merge the pull request, GitHub creates a commit on the base branch that contains all of the changes you made on the head branch since the common ancestor commit.

Because this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request. If there are no conflicts, you can safely merge these commits. However, this workflow makes merge conflicts more likely. If you continue to squash and merge pull requests for a long-running head branch, you will have to resolve the same conflicts repeatedly.

变基与合并拉取请求提交

在 GitHub 上的拉取请求中选择 Rebase and merge(变基并合并)选项时,来自主题分支(或头部分支)的所有提交都会单独添加到基础分支,而无需合并提交。 变基了提交的拉取请求使用快进选项合并。

要变基并合并拉取请求,必须在仓库中拥有写入权限,并且仓库必须允许变基合并

GitHub 上的变基和合并行为与 git rebase 略有偏差。 GitHub 上的变基和合并始终会更新提交者信息并创建新的提交 SHA,而 GitHub 外部的 git rebase 在提交原型上发生变基时不改变提交者信息。 有关 git rebase 的更多信息,请参阅 Pro Git 一书中的“Git 变基”一章

有关 git rebase 的可视表示,请参阅 Pro Git 一书中的“Git 分支 - 变基”一章

在以下情况下,您无法在 GitHub 上自动变基与合并:

  • 拉取请求有合并冲突。
  • 将提交从基本分支变基为遇到冲突的头部分支。
  • 变基提交被视为“不安全”,例如变基可行、不会发生冲突但会产生与合并不同的结果时。

如果您仍然要变基提交,但不能在 GitHub 上自动变基与合并,则您必须:

  • 在命令行上以本地方式将主题分支(或头部分支)变基为基本分支
  • 解决命令行上的任何冲突
  • 强制推送变基的命令到拉取请求的主题分支(或远端头部分支)。

在仓库中具有写入权限的任何人然后可以使用 GitHub 上的变基与合并按钮合并更改

延伸阅读

问问别人

找不到要找的内容?

联系我们