我知道有些人默认使用 git pull --rebase 而其他人则坚持从不使用它。我相信我理解 merge 和 rebase 之间的区别，但我试图将其放在 git pull 的上下文中。只是不想看到很多 merge 提交消息，还是有其他问题？
最佳答案
我想就 git pull --rebase 的实际含义提供一个不同的视角，因为它有时似乎会迷失。
如果您曾经使用过 Subversion(或 CVS)，您可能已经习惯了 svn update 的行为。如果您有更改要提交并且由于上游已进行更改而导致提交失败，则您 svn update。 Subversion 通过将上游更改与您的更改 merge 来进行，这可能会导致冲突。
Subversion 所做的，本质上是 git pull --rebase。重新制定本地更改以相对于较新版本的行为是它的“ rebase ”部分。如果您在失败的提交尝试之前完成了 svn diff，并将生成的差异与之后的 svn diff 的输出进行比较，则两个差异之间的差异就是 rebase 操作做到了。
在这种情况下，Git 和 Subversion 之间的主要区别在于，在 Subversion 中，“您的”更改仅作为工作副本中的未提交更改存在，而在 Git 中，您在本地有实际提交。换句话说，在 Git 中你 fork 了历史；你们的历史和上游的历史不同，但你们有共同的祖先。
在我看来，在让本地分支简单地反射(reflect)上游分支并对其进行持续开发的正常情况下，正确的做法始终是 --rebase，因为这就是你在语义上实际上是在做。你和其他人正在破解一个分支的预期线性历史。其他人碰巧在你尝试推送之前稍微推送了这一事实是无关紧要的，而且每次这样的时间意外都会导致历史 merge ，这似乎适得其反。
如果您出于某种原因真的觉得有必要将某个东西作为一个分支，那么我认为这是一个不同的问题。但是，除非您有一个明确而积极的愿望以 merge 的形式表示您的更改，否则在我看来，默认行为应该是 git pull --rebase。
请考虑其他需要观察和了解您的项目历史的人。您是希望历史上到处都是数百次 merge ，还是只想要代表有意不同开发工作的真正 merge 的精选少数 merge ？
关于git - 什么时候应该使用 git pull --rebase？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2472254/