git - 总是 git pull --rebase master branch 可以吗

Question

我们是一个使用 git 的团队，我们有一个中央存储库(单一来源)，我们用它来 push 和 pull(capistrano 使用它来部署分支大师)

我们定期提交和部署(每天部署 10~20 次)，这意味着我们有很多 merge 提交，git blame 成为一场噩梦

我读过，为了让历史更简单，我们可以使用 git pull --rebase 来避免这种情况。始终在 master 分支上执行此操作是个好主意吗？

如果是，我建议在配置中设置它:

git config branch.master.rebase true

这有什么问题吗？

Answer 1

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

99% 的情况下，对更改进行 rebase 会更好。如果没有，开发人员可以随时中止 rebase 并手动 merge 他们的更改。

替代方案( pull merge )会导致大量没有任何意义的小端提交和 merge 。

一般来说，我不经常看到 merge 本地更改的意义。这意味着开发人员开始使用的确切版本有一些特殊之处，并且以某种方式重新定位到不同的版本会导致信息丢失(也许“我在 Bob 的功能之前开始这个，我想传达它以防万一和 Bob 打得很好，我会受到指责”或其他什么……)。实际上这种情况很少见，清晰的直线提交历史更容易遵循。