git rebase合并提交攻略

本文适合对git rebase命令，尤其是对使用git rebase命令合并提交的方法不太熟悉的开发人员阅读。读者朋友们在阅读过程中如有任何问题，欢迎留言评论。

前言

相信有一定开发经验的朋友对git都不会感到陌生，可能也或多或少听说过git rebase（变基）的大名。作为一个相对来说比较“高级”的git命令，其目的说到底还是为了帮助我们更好的协作。概括来说变基的功能主要有两个：

1. 合并代码¹，类似于merge，但是变基后的分支历史更加简洁
2. 合并提交，把几个实际上干了同一件事的提交合并成一个，目的也是为了简洁

从上面可以总结出，变基追求的就是“简洁²”。简洁的分支历史降低了代码审查的成本，自然也就提高了审查的效率，而代码审查可以说是保证代码质量的最重要的手段之一。本文的主题是功能二。

合并：最简单的情况

作为攻略的开始，我们先来研究一个最简单的情况，如下图所示（git log --oneline）：

提交42e5e66和2856d1f实际上做了同一件事，那就是修改启动成功日志的文案。如果你是代码审查者（实际上，我们自己往往是自己代码的第一个审查者），你肯定希望这两个提交合成一个，这样看起来更方便。那么我们该怎么做呢？
首先我们需要选择一个“参考提交”。什么是参考提交？参考提交是任意一个在我们需要合并的提交之前（更旧）的提交，在这个例子里就是05e4a0a。注意一定要是之前，因为参考提交本身是不参与合并的，举例来说如果你用2856d1f作为参考提交，那就没办法把它和42e5e66合并，因为你在交互界面根本看不到它。
解释完毕，我们开始实操。我们以05e4a0a为参考提交，进入变基操作的交互模式：

git rebase -i 05e4a0a

可以看到：

这个界面是怎么回事呢？可以分成两个部分来看，空行上面是参考提交之后的、我们可以修改的提交历史。空行下面则是说明书，告诉我们可以进行哪些操作，以及这些操作对应的含义。
这里我们需要注意一下提交历史的顺序，最旧的在最上面，但是我们合并是从新往旧合，也就是从下往上合。具体操作一下大家就清楚了，下面我们来合并2856d1f和42e5e66：

• 输入i进入编辑模式；
• 把42e5e66这一行的pick改成f或fixup，如果需要编写新的提交说明，在f或fixup后面添加-c或-C参数；
  
• 改完之后输入:wq确认并退出，如果在上一步添加了-c或-C参数，这时会进入一个新的编辑页面，按照提示编辑后输入:wq确认并退出即可。
  
  到这里就合并成功了。我们再次查看提交历史：
  
  可以看到我们已经成功的把两个提交合并成了一个新的提交。检查代码确定所有变更都在。接下来要做的是把本地的变更推送到远端。

推送：一定要小心

把合并后的提交历史推送到远端，可以分成两种情况来讨论：
第一种，如果修改的提交都是本地提交，换言之都还没有推送到远端的话，这种情况是比较简单的，可以直接拉取或推送，就如同没有修改提交一样。
第二种，如果修改的提交已经推送到远端，这种就比较麻烦了，因为别的用户也许已经基于远端的提交做出修改。这种情况下如果要提交，只能强制提交。
由于强制提交存在一定的风险，建议只修改本地未推送到远端的提交。

修改：更复杂的情况

所谓更复杂的情况，其实就是需要修改更多的提交历史。这里所说的修改不限于本文的主题合并，你也可以调换提交的顺序，只需把要调整的提交所在的行剪切到新的位置就行了，其它的操作和最简单的情况一样。你也可以执行交互界面下方说明书里列出来的任意操作。为了贴合主题，本节的例子还是讲合并，其它操作这里不再演示。请看下面的提交历史：

选定在这四个提交之前的05e4a0a作为参考提交，在交互界面对提交历史进行修改：

将红框中的三个提交与2856d1f合并，同时保留f1b5058，确定并退出后，再次查看提交历史：

合并成功。另外可以看到参考提交之后的提交ID都发生了变化，包括实际上没有参与合并的f1b5058。

参考文档

git-rebase Documentation

---

1. 功能一相对简单，操作和merge差不太多，但是建议各位读者在实际应用之前，一定要弄懂变基到底做了什么事，和merge的区别在哪里，否则小心挨同事锤哈哈。参考链接在此。 ↩︎

2. 虽说功能一和功能二的目的都是为了简洁，但是两个简洁的地方不一样，简单来说一个是合并历史，一个是提交历史，具体的可以参考这个链接或网上的其它资料，这里不再赘述。 ↩︎