git rebase（变基）

认识 git rebase

假设你现在基于远程分支"origin"，创建一个叫"mywork"的分支。

$ git checkout -b mywork origin

现在我们在 mywork 分支做一些修改，生成两个提交(C5和C6).

但是与此同时，有些人也在"origin"分支上做了一些修改并且做了提交了。

你可以用"fetch"命令把"origin"分支上的修改拉下来(但是不合并)；正如下图，"origin"和"mywork"这两个分支“分道扬镳”了。

你可以用"merge"命令把"origin"分支合并到你的分支，这会生成一个合并提交（C7）。

但是，如果你不喜欢分叉与合并，你想让"mywork"分支的历史看起来像一条直线，那你可以用 rebase命令

$ git checkout mywork
$ git rebase origin

这会把分叉之后的"mywork"分支（C5，C6）“嫁接”到“origin”分支的顶端。如下图：

当“mywork”分支更新之后，它会指向最后一个新创建的提交（C6’）. 而那些老的提交（C5，C6）会被Git 的垃圾收集机制丢弃，如下图：

我们可以看一下用 merge 和用 rebase 所产生的历史的区别：

理解 git rebase

之前我们说过git cherry-pick命令（可以参考我的博文git cherry-pick 详解）.

其实“git rebase”就是一系列的“cherry-pick”，只是这一系列的动作用一条命令（git rebase）给完成了。你完全可以通过多次手动“cherry-pick”来复制其行为（不过不太方便，更容易出现人为错误）。

假设你要把 topic 分支 rebase 到 master 分支上

D <-- topic(*)
|
| C <-- master
B |
|/
|
A

你会运行命令：

git checkout topic
git rebase master

在上面的上下文中，“git rebase master”这条命令的潜台词是：

git checkout master # 切换到master分支
git checkout -b topic_rebased # 基于master分支创建并切换一个新分支，比如叫 topic_rebased
for each commit C in master…topic # 对于在topic分支且不在master分支的每个提交 C

git cherry-pick C # 拣选 C 到 topic_rebased 分支
忘记"topic" 的过去，把 topic_rebased 改名为"topic"

过程如下图：

D <-- topic(*)
|
| C <-- master
B |
|/
|
A

D <-- topic
|
| C <-- master, <--topic_rebased(*)
B |
|/
|
A

   B' <-- topic_rebased(*)
D  |
|  |
|  C <-- master
B /
|/
|
A

   D' <-- topic_rebased(*)|B'
D  |
|  |
|  C <-- master
B /
|/
|
A

D' <-- topic(*)
|
B'
|
C <-- master
|
A

在 rebase 的过程中，也许会出现冲突 (conflict)。如果遇到冲突，Git 会停止 rebase，并让你去解决冲突；在解决完冲突后，可以用"git-add"命令去标记此冲突已经解决。然后，你无需执行 git commit,只要执行:

$ git rebase --continue

这样 git 会继续应用余下的补丁。

如果你rebase到一半，突然后悔了，你可以用--abort参数来终止 rebase，并且"mywork" 分支会回到 rebase 开始前的状态。

$ git rebase --abort

----请各位砖家斧正----

【完】

参考资料

【1】https://stackoverflow.com/questions/10058068/in-a-git-cherry-pick-or-rebase-merge-conflict-how-are-base-aka-the-ancestor

【2】http://gitbook.liuhui998.com/4_2.html

【3】https://codeday.me/bug/20180228/136734.html