Question

当我将工作提交到分支A并推送到仓库时，git抱怨我需要更新项目。我通过git pull更新了项目，并完成了自动合并。现在，合并后有两个提交：一个提交是我的更改，另一个提交来自git pull之后的自动合并。

我注意到合并提交已经具有所有已反映在存储库中的更改，因此为什么当所有更改都已反映时git为什么专门为该合并创建另一个提交？有没有办法在我推送之前删除该合并提交？它使不必要的事情变得复杂。合并提交实际上是没有用的。

Answer 1

为避免在提取时创建多余的合并提交，应使用git pull --rebase。您也可以在当前情况下执行它，以摆脱合并提交。

Answer 2

合并将您的本地更改与从服务器获取的更改合并在一起。如果没有本地更改，或者没有从服务器获取新更改，则不会创建合并提交。那可能不是您想要反映变更集成的方式-您可以通过配置或命令行选项来设置其他选项-但是它确实必须以某种方式发生。

特别是，我的意思是-您表示回购中的所有更改都已经考虑在内，没有合并提交。但是必须存在从远程获取的提交，这些提交尚未在本地存储库中进行，否则将没有合并提交。如果您绘制合并提交的历史记录，应该会看到类似

的内容

             R -- S
            /      \
x -- x -- O -- A -- M

其中A是您的本地提交，O是您以前从远程获取的提交，而R和S是从远程获取的提交，您拉了（也基于O）。您可以通过（a）检查M和R或（b）S将diff与M来查看A在做什么。

（一种可能引起混淆的特殊情况，来自服务器的更改的 net 结果可能是“没有更改”。例如，某人提交了R，但随后又还原了{{1 }}，并将其提交为R。结果合并不会产生任何效果，但是git仍然必须这样做以确保分支仅在每次推送时向前移动。）

无论如何，这是默认行为，因为这是将远程更改合并到本地分支中的最简单，最安全的方法。但这不是唯一的方法。您可以要求git将您的本地分支S转到远程分支。然后你会得到

rebase

对于简单的工作流程，这是合理的，并且倾向于遵循最大的重新定级规则-（大致）避免重新编写已经共享的提交。

它确实有成本和风险。来自x -- x -- O -- R -- S -- A'下https://git-scm.com/docs/git-config的文档：

注意：这可能是危险的操作；除非您了解其中的含义，否则不要使用它（有关详细信息，请参见git-rebase [1]）。

您的提交已被pull.rebase取代，A'尚未通过任何单元测试。仅此一项还不错-在“合并”的情况下，M尚未通过任何测试。但是，如果您有更复杂的本地历史记录，则可能许多许多提交都将被重写。这样一来，您可能会遇到许多未经测试的提交，而推动未经测试的提交会使您的生活更加艰难（例如，如果您想使用bisect查找引入了错误的提交）。

此外，可能需要进一步配置以确定如何处理本地历史记录中的合并提交。

对于某些工作流程，例如，如果您经常抽空并期望您不会拥有大量或复杂的本地历史记录，那么收益可能会超过成本；例如，在这种情况下，您可以

git pull --rebase

或通过说

将此设置为默认设置

git config pull.rebase true

Git pull创建了不需要的合并提交

2 个答案: