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来清理本地提交历史。
集成就是一切!
归根到底，merge 和 rebase 都是有用的 Git 策略，用哪个取决于想要实现的目标。合并是非破坏性的，因为合并不会改变现有的历史。另一方面，rebase 可以通过避免不必要的合并提交来帮助清理项目历史记录。只要记住不要在公共分支中这样做，从而避免干扰其他开发人员。
如果想更深入了解高级 Git 工具，可以免费查看“Advanced Git Kit[3]”: 这是关于分支策略、交互式 Rebase、Reflog、子模块等主题的短视频集合。
References:
[1] Rebase vs. Merge: Integrating Changes in Git: https://css-tricks.com/rebase-vs-merge-integrating-changes-in-git/
