git pull创建不需要的合并提交

罗宾

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

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

马克·阿德尔斯伯格

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

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

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

A您的本地提交在哪里O是您以前从远程获取的提交,R并且S是您在拉动时从远程获取的提交(也基于O)。你可以看到什么M是(一)做检查RS,或(b)diff荷兰国际集团M反对A

(一种可能会引起混淆的特殊情况,来自服务器的更改最终结果可能是“无更改”。例如,可能有人提交R但随后将其还原R并提交为S。最终的合并将无效,但是git仍然必须这样做是为了确保分支仅在每次推送时向前移动。)

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

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

对于简单的工作流程,这是合理的,并且倾向于遵循最大的重定基础规则-这(大致)是避免重写已共享的提交。

但是,它确实有成本和风险。从位于https://git-scm.com/docs/git-config的文档pull.rebase

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

您的提交已替换为A',尚未通过任何单元测试。仅此一项还算不错-在“合并”的情况下,M也没有通过任何测试。但是,如果您有更复杂的本地历史记录,则可能会重写许多提交。因此,您最终可能会遇到许多未经测试的提交,而推动未经测试的提交会使您的生活更加艰难(例如,如果您想bisect用来查找引入了错误的提交)。

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

但是,对于某些工作流程-例如,如果您经常拉动,并希望您不会拥有大量或复杂的本地历史记录-收益可能会超过成本。在那种情况下,您可以

git pull --rebase

或将其设置为默认值

git config pull.rebase true

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章