也许最好的解释方式是用一个例子:

Alice creates topic branch A, and works on it Bob creates unrelated topic branch B, and works on it Alice does git checkout master && git pull. Master is already up to date. Bob does git checkout master && git pull. Master is already up to date. Alice does git merge topic-branch-A Bob does git merge topic-branch-B Bob does git push origin master before Alice Alice does git push origin master, which is rejected because it's not a fast-forward merge. Alice looks at origin/master's log, and sees that the commit is unrelated to hers. Alice does git pull --rebase origin master Alice's merge commit is unwound, Bob's commit is pulled, and Alice's commit is applied after Bob's commit. Alice does git push origin master, and everyone is happy they don't have to read a useless merge commit when they look at the logs in the future.

注意，合并到的特定分支与示例无关。本例中的Master可以是一个发布分支或开发分支。关键是Alice和Bob同时将他们的本地分支合并到一个共享的远程分支。

我认为你应该使用git pull -rebase与他人在同一分支上合作。你处于你的工作→提交→工作→提交循环中，当你决定推送你的工作时，你的推送被拒绝了，因为在同一个分支上有并行的工作。在这一点上，我总是做一个拉-rebase。我不使用squash(扁平提交)，但我使用rebase来避免额外的合并提交。

随着Git知识的增长，你会发现自己比使用过的其他版本控制系统更多地关注历史。如果您有大量的小型合并提交，很容易失去对历史中正在发生的大局的关注。

这实际上是我唯一一次执行rebase(*)，其余的工作流程都是基于合并的。但只要你最频繁的提交者这样做，历史最终看起来会更好。

（＊） 在教授Git课程时，我有一个学生因为这个问题逮捕了我，因为我也主张在某些情况下重新定义功能分支。他读到了这个答案;)这种调整基数也是可能的，但它总是必须根据预先安排/商定的制度，因此不应该“总是”适用。在那个时候，我通常也不做拉-rebase，这就是问题所在;)

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

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

也许最好的解释方式是用一个例子:

Alice creates topic branch A, and works on it Bob creates unrelated topic branch B, and works on it Alice does git checkout master && git pull. Master is already up to date. Bob does git checkout master && git pull. Master is already up to date. Alice does git merge topic-branch-A Bob does git merge topic-branch-B Bob does git push origin master before Alice Alice does git push origin master, which is rejected because it's not a fast-forward merge. Alice looks at origin/master's log, and sees that the commit is unrelated to hers. Alice does git pull --rebase origin master Alice's merge commit is unwound, Bob's commit is pulled, and Alice's commit is applied after Bob's commit. Alice does git push origin master, and everyone is happy they don't have to read a useless merge commit when they look at the logs in the future.

注意，合并到的特定分支与示例无关。本例中的Master可以是一个发布分支或开发分支。关键是Alice和Bob同时将他们的本地分支合并到一个共享的远程分支。

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

这里有公共关系部门。

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

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

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

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

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

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

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

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