git rebase作用:相对于git merge的第二种合并分支方法,但是git rebase可以使git提交变得整洁
1. 场景1——合并多次提交
在日常开发中,代码变更比较频繁,有时候想让前几次提交的合并为一次提交,这里可以使用git rebase -i 命令来完成。
命令格式:git rebase -i [startpoint] [endpoint]
-
其中
i
表示interactive的缩写即弹出交互式的界面让用户编辑完成合并操作; -
[startpoint] [endpoint]
则指定了一个编辑区间,如果不指定[endpoint],则该区间的终点默认是当前分支HEAD所指向的commit(注:该区间指定的是一个前开后闭的区间)
执行完命令后,会跳到一个vim编辑器中:
- pick:保留该commit(缩写:p)
- reword:保留该commit,但我需要修改该commit的注释(缩写:r)
- edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e)
- squash:将该commit和前一个commit合并(缩写:s)
- fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f)
- exec:执行shell命令(缩写:x)
- drop:我要丢弃该commit(缩写:d)
注意: 不要把已经在仓库的commit进行合并,避免冲突造成不必要的麻烦
2. 场景2——线性提交记录
参考文章:http://blog.itblood.com/1646.html
rebase 实际上就是取出一系列的提交记录,“复制”它们,然后在另外一个地方逐个的放下去。
Rebase 的优势就是可以创造更线性的提交历史,这听上去有些难以理解。如果只允许使用 Rebase 的话,代码库的提交历史将会变得异常清晰。
-
创建新分支 bugFix分支:
git branch bugFix
-
提交一次(提交在master分支上):
git commit
-
切换到bugFix分支:
git checkout bugFix
-
提交一次(提交在bugFix分支上):
git commit
-
使用git rebase把 bugFix 分支里的工作直接移到 master 分支上(移动以后会使得两个分支的功能看起来像是按顺序开发,但实际上它们是并行开发的):
git rebase master
注意:提交记录 C3 依然存在(树上那个半透明的节点),而 C3’是我们 Rebase 到 master 分支上的 C3 的副本。
- 切换到master分支上(为了进行更新master的操作):
git checkout master
把master的 rebase 到 bugFix 分支上(由于 bugFix 继承自 master,所以 git 只是简单的把 master 分支的引用向前移动了一下而已):git rebase bugFix