1.变基的基本操作
在Git中整合来自不同分支的修改主要有两种方法:merge和rebase。
看下面的例子:开发任务分叉到了两个不同的分支,并且都有了新的提交。
这时候我们可以使用git merge命令将experiment分支合并进入master分支,Git会将C3、C4以及两者最近的共同祖先做一个三方合并,并且生成一个新的提交。如下图所示:
其实我们还可以使用rebase命令:rebase命令将提交到某一分支上的提交都移至另一个分支上
$ git checkout experiment$ git rebase masterFirst, rewinding head to replay your work on top of it...Applying: added staged command
如下图所示:使用rebase之后,将experiment分支上的提交移动到了master分支的后面。
原理:首先找到两个分支(当前所在分支experiment和目标基底分支master)的最近共同祖先(即C2),然后对比当期分支相对于最近共同祖先的所有提交,提取相应的修改存为临时文件,然后将当前分支指向目标基底(即C3),最后将此前存好的临时文件依次应用(理解为将从当前分支上,从最近共同祖先开始的后一个提交节点,开始复制,放到目标基底后)。
完成rebase操作之后,可以运行以下命令,进行一次快速移动。
$ git checkout master$ git merge experiment
操作完成之后,提交历史如下图所示。
与直接使用merge命令相比,rebase命令可以使提交历史更加的整洁,看上去就像是一条直线。使用rebase的目的是是提交历史看起来更加的整洁,其实,无论是通过merge还是rebase,整合的最终结果都是一样的,只不过rebase的提交历史看起来更加的整洁。rebase是将一系列提交按照原有次序依次应用到另一分支上,而merge是将最终结果merge在一起。
2.rebase VS merge
对于rebase和merge哪种好,有两种观点:
1.有一种观点认为,仓库的提交历史即是记录着实际上发生过什么,它是一种历史文档,本身具有价值,不能随意修改,这些历史应该被保留下来,供后人进行查阅。这种观点支持使用merge而不是rebase。
2.另一种观点正好相反,他们认为提交历史是项目开发过程中发生的事情,没有人会出版一本书的第一版草稿,都是需要进行多次修订之后才能进行出版的,修订之前的这些历史不应该被读者看到。这种观点鼓励使用rebase。
总的原则:只对尚未推送或分享给他人的本地修改执行rebase操作清理历史,从不对已经提交到别处的提交进行rebase操作。