赞
踩
在项目开发的过程中,git作为版本管理工具重要性不言而喻。平常大家肯定会使用merge命令来合并分支。然而merge来合并分支有个缺点,就是当分支太多,合并太多,那么提交记录的图谱看起来就非常丑。
以上,而rebase
就可以解决这个问题。下文我将使用git官方的例子来解释一下rebase
与fast-forward
在实际中的应用。
假设我们有一下的场景:
iss53
hotfix
下面用图片来形象的描述一下:
初始状态:
创建新的分支
$ git checkout -b iss53
Switched to a new branch "iss53"
编辑了新分支
$ vim index.html
$ git commit -a -m 'Create new footer [issue 53]'
因修复紧急bug,创建新分支hotfix
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m '修复紧急bug'
[hotfix 1fb7853] 修复紧急bug
1 file changed, 2 insertions(+)
下面重头戏来了。我们知道如果要上线这个紧急bug,需要将hotfix
分支合并回master
。
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
可以看到,合并的过程已经发生了fast-forward。我们可以简单的这样理解:当hotfix分支是基于master最新的提交进行开发的时候,就会发生fast-forward。
究其原因,因为git合并分支需要有一次新的提交(可以看后边继续的例子)。然而当git发现,像上边的情况,产生新的提交没有意义的时候(因为hotfix就是基于master最新的提交),这时候就会自动触发fast-forward。
当然你可以禁止fast-forward。即在合并的时候指明--no-ff
的参数,那么无论如何都将会产生一次新的提交。
接下来,紧急bug已经修复了,我们继续切回到iss53
来修改代码,并最终提交。
如上图,此时hotfix分支没用了,被删除了。接下来再次把iss53合并到master。
$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html | 1 +
1 file changed, 1 insertion(+)
值得注意是,这次是没有发生fast-forward。因为iss53
并不是基于master的最新一次提交。二者合并的时候理应产生一个新的合并的提交,即下图中的C6
。
现在。我们回到开始的问题。这样做会导致将来的图谱太丑。其实解决方法也很简单,只要让C3
从指向c2
变成指向c4
即可。也就是指向master分支的最新一次提交。而这个操作就是rebase。
rebase之后,再进行合并就是触发fast-forward
,也就是不会真的合并产生一个提交。
$ git rebase master
Successfully rebased and updated refs/heads/iss53.
最后再次合并iss53至master。你就可以发现图谱就会很干净了。
参考:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。