问什么时候应该使用git pull --rebase？

想提供一个不同的角度来看“git pull --rebase”究竟意味着什么，因为它似乎有时会迷失方向。

如果你曾经使用过颠覆（或CVS），你可能习惯了“svn update”的行为。如果你有更改提交，并提交失败，因为已经做了上游改变，你“svn更新”。Subversion通过合并上游的变更，从而导致冲突。

颠覆者刚刚做了什么，实质上是“拉回”。重新制定你的本地变化是相对于较新版本的行为是“重新定位”的一部分。如果在失败的提交尝试之前完成了“svn diff”，之后将得到的diff与“svn diff”的输出进行比较，那么两次差异之间的区别就是重新构建操作所做的。

在这种情况下，git和subversion之间的主要区别是，在subversion中，“你的”更改只存在于工作副本中未提交的更改中，而在git中则有本地实际的提交。换句话说，在git中，你分叉了历史; 你的历史和上游历史已经分歧，但你有一个共同的祖先。

在我看来，在你的本地分支只是简单地反映上游分支并对其进行持续开发的正常情况下，正确的做法总是“--rebase”，因为这就是你在语义上实际做的事情。你和其他人正在窃取分支的预期线性历史。事实上，在你试图推动之前，其他人碰巧推迟了这一事实是无关紧要的，而且对于每一次这样的时间事故都会导致历史合并，这似乎是反效果的。

如果你真的觉得无论出于什么原因都需要某个分支，那么在我看来这是一个不同的问题。但是，除非你有一个具体而积极的愿望，以合并的形式来表达你的改变，否则在我看来，默认行为应该是“git pull --rebase”。

请考虑其他需要观察和了解项目历史的人。你是否希望历史上遍布着数以百计的合并历史，还是只想要有意合并的有意识的发展努力的少数合并？

在Git中，你可能知道，鼓励你分支和合并。你所在的本地分支，以及远程分支，实际上是不同的分支，并且git pull正在合并它们。这是合理的，因为你不太经常推动，通常积累一些变化，才构成一个完整的功能。

然而，有时 - 无论出于什么原因 - 你认为如果这两个遥远的和本地的分支是一个分支，情况会更好。像在SVN中一样。这是在哪里git pull --rebase发挥作用。你不再合并 - 你实际上在远程分支上进行提交。这就是它的实际情况。

无论危险与否，您是否将本地与远程分支视为一个不可分割的东西。有时这是合理的（当你的变化很小，或者如果你刚刚开始一个强大的开发，当小的提交带来重要的变化时）。有时不是（当你通常创建另一个分支，但你太懒了）。但这是一个不同的问题