一个实践案例是当你与Bitbucket PR合作时。 让我们用下面的例子来理解它:

这里有公共关系部门。

然后你决定通过BitBucket GUI用最新的Master分支重新构建PR远程分支。这个操作将改变你的PR的提交id。

因为您已经使用GUI重新创建了远程分支。首先，你必须同步你电脑上的本地分支和远程分支。

在这种情况下，git pull -rebase就像魔法一样有效。

在git pull -rebase之后，你的本地分支和远程分支具有相同的历史和相同的提交id。

那么现在，如果您向PR分支添加一个新的提交/更改。

你可以很好地推送一个新的提交，而不需要使用强制或任何东西到远程分支/BitBucket PR。

我不认为有任何理由不使用pull——rebase——我专门为Git添加了代码，以允许我的Git pull命令始终针对上游提交进行rebase。

当我们回顾历史的时候，我们总是不愿意知道那些致力于某一功能的人何时停止了工作。当他/她在做这件事的时候，它可能对男人/女孩有用，但这就是reflog的目的。这只是给其他人增加了噪音。

只需记住:

Pull = fetch + merge Pull—rebase = fetch + rebase

因此，选择您想要处理分支的方式。

你最好知道merge和rebase的区别:)

我想提供一个不同的角度来解释git pull -rebase的实际含义，因为它似乎有时会丢失。

如果您曾经使用过Subversion(或CVS)，那么您可能已经习惯了svn update的行为。如果要提交更改，并且由于上游已经进行了更改而导致提交失败，则svn update。Subversion通过将上游更改与您的更改合并进行，这可能会导致冲突。

Subversion刚刚做的，本质上是git pull -rebase。将您的局部更改重新定义为相对于新版本的行为是“重基”的一部分。如果您在失败的提交尝试之前执行了svn diff，并将结果diff与之后的svn diff输出进行比较，那么这两个diff之间的差异就是重基操作所做的。

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

In my opinion, in the normal case of having your local branch simply reflecting the upstream branch and doing continuous development on it, the right thing to do is always --rebase, because that is what you are semantically actually doing. You and others are hacking away at the intended linear history of a branch. The fact that someone else happened to push slightly prior to your attempted push is irrelevant, and it seems counter-productive for each such accident of timing to result in merges in the history.

在我看来，如果出于某种原因，您确实觉得有必要将某些东西作为一个分支，那就另当别论了。但是，除非您有一个特定的和积极的愿望，以合并的形式表示您的更改，在我看来，默认的行为应该是git pull -rebase。

请考虑其他需要观察和理解项目历史的人。您是希望历史上到处都是数百个合并，还是希望只选择代表有意的不同开发工作的真正合并的少数合并?

Git pull -rebase可能会从合作者Git push -force中隐藏历史重写。我建议只有当你知道你忘记在其他人做同样的事情之前推送你的提交时，才使用git pull -rebase。

如果你没有提交任何东西，但你的工作空间不干净，只是在git隐藏之前要git拉。这样你就不会默默地重写你的历史(这可能会默默地丢掉你的一些工作)。

这个场景描述了这样一种情况:由于原始代码被更改，您无法推送提交。科迪的解释很容易理解。我画了一个图表来描述这个场景，希望对大家有所帮助。如果我错了，请指正。