总是在主分支上执行git pull --rebase是否可行？

Question

我们是一个使用 git 进行工作的团队，我们拥有一个中央仓库（单一远程仓库），我们用它来进行 push 和 pull（而 capistrano 则用它来部署主分支）。

我们经常进行提交和部署（每天 10~20 次），这意味着我们有很多合并提交，在这种情况下，使用 git blame 变得非常困难。

我读到过可以使用 git pull --rebase 来简化历史记录，这个做法是否总是适用于主分支？

如果是的话，我建议在配置中设置如下：

git config branch.master.rebase true

这个有问题吗？

- Mathieu

Answer 1

完全没有问题。 实际上，这是首选的。

99% 的情况下，重新制作变更要好一些。 如果不是这样，开发人员始终可以中止变基并手动合并其更改。

另一种方法（在拉取时合并）会导致大量不贡献任何含义的小侧面提交和合并。

总的来说，我经常看不到将本地更改合并的意义。 这意味着开发人员开始的确切版本有点特殊，以某种方式重定位到不同版本会导致信息丢失（也许是“我在 Bob 的功能之前开始了这个项目，如果它与 Bob 不兼容，我想传达这一点，以防责怪我”之类的事情…）。 这很少是真实情况，一个干净的直线提交历史更容易跟进。

- Michael Haefele

Answer 2

默认情况下使用pull rebase是可行的（不一定是一个“好主意”，也不一定是一个“坏主意”）。但您需要记住，它将重新提交您的工作。如果您进行了一系列依赖于Bob更改之前存储库中内容的提交¹，则您的rebase（在Bob的更改顶部）可能会迫使您修复所有这些提交，而修复最终合并提交可能更容易一些。

我更喜欢手动完成此操作：运行git fetch，然后根据情况运行git rebase或git merge，我可以在执行fetch后发现其中的情况。

但是，git pull --rebase（和/或设置branch.master.rebase true）有一个优点，即“带rebase的pull”特别聪明，并且可以处理一些远程已经进行的rebase情况。

---

¹这里的“Bob”代表任何进行了某些更改（并且比您更快地进行了push步骤），从而导致您自己的更改“消化不良”。

- torek

Answer 3

在我的经验中，使用pull.rebase是很好的选择。如果你不想出现合并冲突，可以在本地分支上工作；如果你想使用最新的代码，那么推送当前工作之前，请确保没有未提交的更改。

通过git pull合并分支几乎总是没有意义的，如果合并是有意义的话，分支应该是不同的（并且需要显式合并）。

另请参见http://stevenharman.net/git-pull-with-automatic-rebase。

- TuteC

Answer 4

如果有其他人在另一个仓库中使用某个修订版本并基于它进行了其他工作，那么您就不应该对其进行任何变基操作，因为这将需要对该工作进行变基。

如果您推送了一个分支，然后对其进行了变基，那么您将不得不使用-f选项进行下一次推送。因此，如果您从未使用过该选项，则永远不会遇到问题，并且可以自由地进行变基。但是，如果您使用-f进行推送，可能是到一个功能分支上，请注意不要在其他人可能正在使用该分支时进行变基，或者与他们协调变基。

因此，对于您自己的开发工作，尽管进行变基（以及变基-i和组合和拆分更改等使它们更加逻辑化）。但是，如果超过一个人在一个功能上工作，则需要协调变基，这可能不再值得，而且变基已发布的开发分支基本上是禁止的。

- Jan Hudec

---

由于我们只从中央仓库拉取/推送，因此没有人可以从“我的”主分支中拉取，因此我无法通过git pull --rebase master将其他存储库中存在的工作进行变基。是吗？当然，只有在未发布功能分支时才会进行变基。我只是在谈论主分支。 - Mathieu

@Mathieu：没有人能拉取您的主分支，但是如果您将主分支推送到中央仓库的开发分支中，则其他人可以使用它，那么您就不应该对其进行变基。 - Jan Hudec

除非您使用 -f 推送主分支或将其推送到从未与主存储库重新同步的不同上游存储库，否则此答案是错误的。如果您不这样做，则被重写的历史记录定义为受限于未共享本地提交。 - Chris Adams

@ChrisAdams: 不过，这怎么能说明这个答案是 错误 的呢？如果你不用 -f 推送（它不必特指_master_；你可以使用 -f 推送一个功能分支，而其他人可能需要合并它），你就不会遇到问题。但这并不意味着这种情况没有问题。 - Jan Hudec

你不应该对其他仓库中存在并可能有其他工作基于它的任何修订进行变基，因为那个工作也需要被变基。如果你总是只对尚未共享的提交进行变基（即git pull --rebase master实际执行的操作），那么这句话所说的情况就不存在了。 - Chris Adams

@ChrisAdams：问题是问是否总是可以。因此，我解释了什么情况下不行。是的，这不是标准情况。但并不是说不可能发生——我们有许多分支，多个人在上面工作。 - Jan Hudec