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

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

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

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

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

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

where A是你的本地提交，O是您之前从远程获取的提交，并且R and S是当您拉取时从远程获取的提交（也基于O）。你可以看到什么M正在通过（a）检查R and S，或（b）diffing M反对A.

（一种可能令人困惑的特殊情况，net服务器更改的结果可能是“无更改”。例如，也许有人犯了R但后来又恢复了R并承诺作为S。由此产生的合并不会产生任何效果，但 git 仍然必须这样做以确保分支仅在每次推送时向前移动。）

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

x -- x -- O -- R -- S -- A'

对于简单的工作流程，这是合理的，并且它往往符合变基的最大规则——（大致）它避免重写已经共享的提交。

但它确实有成本和风险。来自文档https://git-scm.com/docs/git-config https://git-scm.com/docs/git-config under pull.rebase:

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

您的提交被替换为A'，尚未通过任何单元测试。仅此一点还不算太糟糕 - 在“合并”的情况下，M也还没有通过任何测试。但如果你有更复杂的当地历史，那么可能many提交将被重写。因此，您最终可能会得到许多未经测试的提交，并且推送未经测试的提交可能会让以后的生活变得更加困难（例如，如果您想使用bisect找到引入错误的提交）。

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

尽管如此，对于某些工作流程（例如，如果您经常拉取并期望不会有大量或复杂的本地历史记录），收益可能会超过成本；在这种情况下你可以

git pull --rebase

或者将其设置为默认值

git config pull.rebase true