问将团队从Git Merge切换到Rebase

EN

在我看来，混合使用merge和rebase的主要问题是，当您执行rebase时，它会“线性化”历史记录，而这对于merge commits并不能很好地工作。但随着历史变得更简单、更容易推理，线性化本身实际上也有其优点。

最简单的策略就是避免合并。在这个时候，人们可能会说git merge X do git rebase X。

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

对共享分支机构进行改基时要特别注意。当重新建立这些基础时，将需要人类同步，许多人希望完全避免它，请参见以下内容：

另一种方法是在开发过程中接受上游的合并，并在合并回/发出拉取请求之前执行，例如：

 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和rebase才能使用git (尤其是在gerrit中)。

一些例子..。

当您将您的功能分支提升到新的远程主机时，您将合并。这只提供了最少的提升工作，并且很容易跟踪特性开发的历史，例如gitk。

git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature

您可以在准备交付提交时进行合并(使用--squash选项，因为在master中不允许合并提交)。

git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master

当交付提交由于某种原因导致集成失败，并且您需要将其更新为新的远程主机时，您可以重新设置基址。

git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master