git - 将团队从 Git Merge 切换到 Rebase

Question

我们的研发使用两个中央存储库，最初由非常顽固的聪明人开始，一个使用 rebases，另一个使用 gitflow 和 merge 。虽然我很习惯使用 merge ，而且我看到大多数 github 项目都使用这种模式，但我们面临着遵守“ rebase ”的压力，因为我们正在转向更有组织的 Gerrit 代码审查系统，而且许多开发人员正在转向我们的来自其他团队的 repo。

就是这样:手册页警告我永远不要混合 rebase 和 merge ，现在我必须更换我的整个团队。我想知道如何在不对我们代码的稳定性造成太大风险的情况下做到这一点。人们总是有一个或两个开放的功能分支，并且在开发过程中可能会多次从 dev merge 。这样的特性分支是否可以只切换到 rebase ，或者截止日期应该只有在所有特性分支首先被 merge 并且自 fork 以来不存在分支历史 merge 之后？我如何计划这是一个平稳的过渡？

Answer 1

我看到混合 merge 和 rebase 的主要问题是，当你进行 rebase 时，它会“线性化”历史，这对 merge 提交来说效果不佳。但随着历史变得更简单、更容易推理，线性化本身实际上有其优点。

最简单的策略确实是避免 merge 。现在人们早先会说 git merge X 而不是 git rebase X 。

这并没有那么糟糕，除非您在本地分支中有多个提交并且其中一个在 rebase 时产生了 merge 冲突。对同一地点的进一步提交可能会一次又一次地产生相同的 merge 冲突。在这种情况下，解决方法可能是中止 rebase git rebase --abort 并使用 git rebase --interactive 重新安排本地提交或压缩本地提交(git重置 $(git merge-base HEAD X)).之后重复 rebase 。

在进行 rebase 时应特别注意共享分支。重新设置基准时需要人工同步，许多人宁愿完全避免它，见下文:

另一种方法是在开发过程中接受来自上游的 merge ，并在 merge 回/发出 pull 请求之前进行压缩，例如:

 git checkout -b Work
 #work...commit...commit..
 git merge X
 #work...commit...commit..
 git merge X
 git reset X && git add . && git commit -m 'All my work squashed'
 #alternatively the last part might be like this:
 git checkout X && git merge --squash Work

这种方法的优点是您可以相对安全地共享这样的分支，而无需人工通信的开销。与在另一个分支之上重播一个分支相比， merge 两个分支通常更容易解决冲突。