git 合并代码之--merge、rebase

2018-02-27 11:20:06来源:https://www.jianshu.com/p/6f8484503c8b作者:T9的第三个三角人点击

分享


git最常用方法之一,合并代码,大部分时候我们都是使用merge命令。其实还有rebase命令,既然都是合并代码,两者有什么差异和共同点?
那就来深入了解一下


1.相同点

虽然git合并代码有merge和rebase两种方式,但是两种合并方式的最终结果是一样的,没有任何区别。


既然整合结果没有区别,那么区别在哪了?那就是合并过程。


2.不同点

以两个分支为例,主分支master,新分支develop,将develop分支合并到master主分支


2.1. merge合并
//当前处于master分支
daideMacBook-Pro:UIFinalTest dai$ git status
On branch master
Your branch is ahead of 'github/master' by 5 commits.
(use "git push" to publish your local commits)
//创建并切换到develop分支
nothing to commit, working tree clean
daideMacBook-Pro:UIFinalTest dai$ git checkout -b develop
Switched to a new branch 'develop'
//创建一个类,添加到develop仓库
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Develop1'
[develop 905f008] Develop1
Committer: dai <dai@daideMacBook-Pro.local>
//切换到master分支,并添加一个类到master仓库
daideMacBook-Pro:UIFinalTest dai$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'github/master' by 5 commits.
(use "git push" to publish your local commits)
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Master1'
[master 4d82b67] Master1
Committer: dai <dai@daideMacBook-Pro.local>
//再次添加一个类到master仓库
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Master2'
[master 3a2c545] Master2
Committer: dai <dai@daideMacBook-Pro.local>
//最后,再回到develop分支,添加一个类到develop仓库
daideMacBook-Pro:UIFinalTest dai$ git checkout develop
Switched to branch 'develop'
daideMacBook-Pro:UIFinalTest dai$ git add .
daideMacBook-Pro:UIFinalTest dai$ git commit -m'Develop2'
[develop 78d53bf] Develop2
Committer: dai <dai@daideMacBook-Pro.local>

因为master和develop的父分支是一样的,都是base,所以具体流程如下:
master: base <--- Master1 <--- Master2
develop: base <--- Develop1 <--- Develop2




image.png

合并代码:


//先切换到master分支,使用git merge develop命令
daideMacBook-Pro:UIFinalTest dai$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'github/master' by 7 commits.
(use "git push" to publish your local commits)
daideMacBook-Pro:UIFinalTest dai$ git merge develop

因为使用merge命令是按照时间戳先后顺序的,所以,得到的提交历史为:
base <--- Develop1 <--- Master1 <--- Master2 <---Develop1 <--- Merge(做了三方合并发现冲突,手工处理冲突后git add/commit增加了提交节点Merge)





image.png
2.2 rebase合并

分支创建同上,但是在合并代码时,不需要切换到master分支


合并代码:


daideMacBook-Pro:UIFinalTest dai$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Develop1
Applying: Develop2

1:回到两个分支(master、develop)的共同祖先(base),


2:提取你所在分支(develop)每次提交时产生的差异,


3:把这些差异分别保存到临时文件里,


4:然后从当前分支(develop)转换到你需要衍合的分支(master),


5:依照顺序把分支master的差异commit放到分支feature-1中。






合并后的 Develop2(即现在的 Develop2`)所指的快照,同上面Merge三方合并例子中的 Merge所指的快照内容一模一样了。最后整合得到的结果没有任何区别,但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录,看起来更清楚: 仿佛所有修改都是先后进行的,尽管实际上它们原来是同时发生的。


总结

git rebase过程相比较git merge合并整合得到的结果没有任何区别,但是通过git rebase衍合能产生一个更为整洁的提交历史。
如果观察一个衍合过的分支的历史提交记录,看起来会更清楚:仿佛所有修改都是在一根线上先后完成的,尽管实际上它们原来是同时并行发生的。


一般我们使用衍合的目的,是想要得到一个能在远程分支上干净应用的补丁,比如某个项目你不是维护者,但是想帮点忙,最好使用衍合处理。
先在自己的一个分支进行开发,当准备向主项目提交补丁的时候,根据最新的orgin/master进行一次衍合操作然后再提交,这样维护者就不需要任何整合工作。


实际为:把解决分支补丁同最新主干代码之间的冲突的责任,划转给由提交补丁的人来解决。
作为维护项目的人只需要根据你提供的仓库地址做一次快进合并,或者直接采纳你提交的补丁。


衍合的风险,请务必遵循如下准则:
一旦分支中的提交对象发布到公共仓库,就千万不要对该分支进行衍合操作。








最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台