Git rebase 的使用

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase

Git rebase 概念

**rebase概念：**用来重新应用提交（commits）到新的基础提交上

理解：

• 我们可以将其理解成改变当前分支的base；
• 比如在分支 hotfix 上执行rebase master，那么可以改变 hotfix 的base为master

**作用：**保持提交历史的线性化，避免分叉提交记录。

结合案例理解：

背景：我们需要在 c2 创建 hotfix 分支进行修复 bug

Plan1：采用 merge 来实现

git merge的操作如下所示，bug修复完后，在 master 上合并 hotfix 分支

通过 log 查看 图结构，如下所示：

nathanchen@192 rebase % git merge hotfix           
Merge made by the 'ort' strategy.
 foo.js | 1 +
 1 file changed, 1 insertion(+)
nathanchen@192 rebase % git log --pretty=oneline --graph
*   64e94a94dc6464bb42fc0c4f48419479d141d335 (HEAD -> master) Merge branch 'hotfix'
|\  
| * 04d6400f44b01ca420ef69bcad1a47e5310d5a6f (hotfix) hotfix commit
* | 8e3ebf3371cf5b2b95dabccfb57828f443df1f79 3 commit
|/  
* ec7d26252df6bb104ea15c85e8bbbffa4fe37818 2 commit
* 132fad134c2d9e7de97fcac8d105c416afda613c 1 commit
* c90491eb34784dd0a4f98184c6d44b80a32f4120 init commit
(END)

根据以上来看， 采用git merge 来合并分支会导致分支非线性。

---

Plan2：采用 rebase 来实现

目前情况如下所示，当前 hotfix 分支的base为c2

我们需要在 hotfix 上进行 rebase 操作，即我们需要在 hotfix 分支上将base改成 master 指向的提交对象c3，命令如下所示：

git rebase master

整体流程如下：

nathanchen@192 rebase % git checkout hotfix             
Switched to branch 'hotfix'
nathanchen@192 rebase % git rebase master  
Successfully rebased and updated refs/heads/hotfix.
nathanchen@192 rebase % git log --pretty=oneline --graph
* 5a3569383a81896decb866f5333ed0abd2bd2e46 (HEAD -> hotfix) hotifx commit
* 9e5912ce9fe64627394302d8dce03958aa41bc2a (master) 3 commit
* 3971f63e84c77d0266658a61283ceafc543b0c5b 2 commit
* 959e6c99e08492212666970d2af79bc3c4378979 1 commit
* cbddbfed8dc69ddb04b19bb2fef704b6ac94b5cb init commit
(END)
nathanchen@192 rebase % git checkout master             
Switched to branch 'master'
nathanchen@192 rebase % git log --pretty=oneline --graph
* 9e5912ce9fe64627394302d8dce03958aa41bc2a (HEAD -> master) 3 commit
* 3971f63e84c77d0266658a61283ceafc543b0c5b 2 commit
* 959e6c99e08492212666970d2af79bc3c4378979 1 commit
* cbddbfed8dc69ddb04b19bb2fef704b6ac94b5cb init commit

此时的git提交图结构如下所示：

我们需要将 master 指向最新的提交对象 hotfix

nathanchen@192 rebase % git merge hotfix                
Updating 9e5912c..5a35693
Fast-forward
 foo.js | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 foo.js
nathanchen@192 rebase % git log --pretty=oneline --graph
* 5a3569383a81896decb866f5333ed0abd2bd2e46 (HEAD -> master, hotfix) hotifx commit
* 9e5912ce9fe64627394302d8dce03958aa41bc2a 3 commit
* 3971f63e84c77d0266658a61283ceafc543b0c5b 2 commit
* 959e6c99e08492212666970d2af79bc3c4378979 1 commit
* cbddbfed8dc69ddb04b19bb2fef704b6ac94b5cb init commit

最终的git提交图结构如下所示：

---

---

Git rebase 原理

rebase工作原理：

首先找到这两个分支（即当前分支 hotfix、变基操作的目标基底分支 master） 的最近共同祖先 C2；

然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件；

接着将当前分支指向目标基底 C3；

最后将之前存储的临时文件的修改依序应用；

我们可以再次执行master上的合并操作：

$ git checkout master 
$ git merge experiment

---

---

rebase和merge的选择

开发中对于rebase和merge的选择：

事实上，rebase和merge是对Git历史的不同处理方法：

merge用于记录git的所有历史，那么分支的历史错综复杂，也全部记录下来；

rebase用于简化历史记录，将两个分支的历史简化，整个历史更加简洁；

了解了rebase的底层原理，就可以根据自己的特定场景选择merge或者rebase。

rebase的黄金法则：永远不要在主分支上使用rebase

• 如果在main上面使用rebase，会造成大量的提交历史在main分支中不同；
• 而多人开发时，其他人依然在原来的main中，对于提交历史来说会有很大的变化；

理解以上：

rebase前

在master上rebase，会导致c3的base变成hotfix2，导致历史混乱。

在hotfix上rebase：