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

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

你应该使用git pull -rebase when

您的更改不值得一个单独的分支

的确——那为什么不呢?它更清晰，并且没有对提交进行逻辑分组。

好吧，我想需要澄清一下。在Git中，您可能知道，鼓励您进行分支和合并。你的本地分支和远程分支，实际上是不同的分支，git pull是关于合并它们。这是合理的，因为你不经常推送，而且通常在它们构成一个完整的功能之前会积累一些更改。

然而，有时——不管出于什么原因——您认为如果这两个分支(远程和本地)是一个分支实际上会更好。就像在SVN中。这就是git pull -rebase发挥作用的地方。你不再合并——你实际上是在远程分支上提交。这才是它真正的意义所在。

是否危险的问题是你是否把本地分支和远程分支视为一个不可分割的东西。有时这是合理的(当您的更改很小时，或者如果您处于健壮开发的开始阶段，当通过小型提交带来重要的更改时)。有时不是(当您通常创建另一个分支，但您太懒了)。但这是另一个问题。

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

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

如何使用git拉

git pull: Update your local working branch with commits from the remote, and update all remote tracking branches. git pull --rebase: Update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit. git pull --force: This option allows you to force a fetch of a specific remote tracking branch when using the option that would otherwise not be fetched due to conflicts. To force Git to overwrite your current branch to match the remote tracking branch, read below about using git reset. git pull --all: Fetch all remotes - this is handy if you are working on a fork or in another use case with multiple remotes.

只需记住:

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

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

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

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

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

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

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