Git rebase 的使用(结合图与案例)
目录
- Git rebase 的使用
- Git rebase 概念
- Git rebase 原理
- rebase和merge的选择
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: