Git进阶系列 | 5. Rebase vs Merge

Git是最流行的代码版本控制系统，这一系列文章介绍了一些Git的高阶使用方式，从而帮助我们可以更好的利用Git的能力。本系列一共8篇文章，这是第5篇。原文：Rebase vs. Merge: Integrating Changes in Git^[1]

大多数开发人员都理解在Git中使用分支的重要性，事实上，本系列已经有一篇关于Git分支策略的文章，解释了Git强大的分支模型、不同类型的分支以及两种最常见的分支工作流。总而言之，在独立的容器中工作（即分支），是非常有用的，也是使用版本控制系统的主要原因之一。

本文我们将研究如何集成分支，如何将新代码添加回现有的开发线路中？有不同的方法可以实现这一点。在这篇“Git进阶”系列的第五部分我们要讨论Git中的集成更改，即合并和rebase。

在我们深入细节之前，重要的是要理解这两个命令，git merge和git rebase。它们解决了相同的问题，即将一个Git分支的更改集成到另一个分支，只是做法稍有不同。下面我们从git merge开始。

Git进阶系列:

创建完美的提交

Git中的分支策略

基于Pull Request实现更好的协作

合并冲突

Rebase vs Merge（本文）

交互式Rebase

Git中的Cherry-pick提交

用Reflog恢复丢失的提交

理解合并

要将一个分支合并到另一个分支，可以使用git merge命令。假设在ranch-B上有一些新提交，现在我们想把这个分支合并到另一个分支branch-A中。为此，可以这样输入:

$ git checkout branch-A
$ git merge branch-B

如此，Git会在当前工作分支(本例中为branch-A)中创建一个新的合并提交，连接两个分支的历史记录。为了完成这个任务，Git需要查找三个提交:

第一个是“公共祖先提交(common ancestor commit)”。如果跟踪一个项目中两个分支的历史，总是至少有一个公共提交。此时，两个分支具有相同的内容。在那之后，就向不同方向进化。
另外两个有趣的提交是每个分支的端点，即它们的当前状态。请记住，集成的目的是组合两个分支的当前状态。因此，他们的最新修订当然很重要。

结合这三个提交可以执行我们想要的集成。

无可否认，这是一个简化场景，两个分支中的一个(branch-A)自创建以来没有任何新的提交，这在大多数软件项目中是不太可能的。因此，它在本例中的最后一次提交也是公共祖先(common ancestor) 。

在这种情况下，集成非常简单，Git可以将所有来自branch-B的新提交添加到公共祖先提交之上。在Git中，这种最简单的集成形式称为“快进(fast-forward)”合并，然后两个分支共享完全相同的历史(并且不需要额外的“合并提交”)。

然而大多数情况下，两个分支将以不同的提交向前推进。我们举一个更现实的例子:

为了集成，Git必须创建一个包含所有更改的新提交，并注意分支之间的差异，这就是我们所说的合并提交(merge commit) 。

人工提交和合并提交

通常情况下，提交是由人精心创建的，是一个有意义的单元，只包含相关的变更，以及包括了上下文和注释的有意义的提交信息。

现在，合并提交有点不一样，它不是由开发人员创建的，而是由Git自动创建的。而且，合并提交不一定包含“相关更改的语义集合”。相反，它的目的只是连接两个(或更多)分支。

如果想了解这样的自动合并操作，必须查看所有分支的历史以及各自的提交历史。

Rebase集成

在讨论rebase之前，先说清楚一点: rebase并不比合并更好或更差，只是不同而已。也许你只需要通过合并集成分支，就可以完成工作，甚至不需要考虑rebase。不过，理解rebase是做什么的，并了解它的优缺点，确实很有帮助。也许你会在某个项目中遇到某个问题，而rebase恰好很有帮助…

好吧，我们开始！还记得刚刚讲的自动合并提交吗？有些人不太喜欢这些，宁愿不用。另外一些开发人员喜欢项目历史看起来像一条直线，没有任何迹象表明它在某个点上被分成了多个分支，即使这些分支已经被集成了。这基本上就是Git rebase过程中发生的事情。

一步一步rebase

让我们逐步介绍rebase操作。和前面的例子一样，一开始是这样的:

我们想要将branch-B的更改集成到branch-A中，但这次是用rebase，而不是合并。实际的Git命令非常简单:

$ git checkout branch-A
$ git rebase branch-B

类似于git merge命令，只需要告诉git想要集成哪个分支。我们来看看幕后故事……

第一步，Git将“删除”发生在公共祖先提交之后的所有对branch-A分支的提交。别担心，它们不会被丢弃，可以将这些提交视为被暂时保存在一个安全的地方。

第二步，Git应用来自branch-B的新提交。此时，两个分支暂时看起来完全相同。

最后，集成那些“暂存”的提交(来自branch-A的新提交)。由于它们位于branch-B分支的顶部，所以是rebase的。

因此，项目历史看起来就像是在一条直线上进行开发，不存在包含所有合并更改的合并提交，并且保留了原始提交结构。

rebase的潜在隐患

还有一件事对于理解Git rebase很重要，它重写了提交历史。再看一下最后一张图表，提交C3*带有星号，虽然C3*与C3具有相同的内容，但实际上是不同的提交。为什么？因为它在rebase之后有一个新的父提交。在rebase之前，C1是父提交。在rebase之后，父提交是C4，它被rebase到了C4。

一个提交只有少量重要属性，比如作者、日期、变更集和父提交，更改任何这些信息都会创建一个全新的提交，有一个新的SHA-1哈希ID。

对于尚未发布的提交，这样重写历史记录不是问题。但是，如果正在重写的是已经推送到远端代码库的提交，可能会遇到麻烦。也许其他人的工作是基于最初的C3提交的，现在它突然不存在了……

为了远离麻烦，这里有一个使用rebase的简单规则: 永远不要在公共分支上使用rebase，比方说已经被推送到远端代码库的提交！相反，只在将它集成到共享的团队分支之前，才使用git rebase来清理本地提交历史。