以前用习惯了svn,一直觉得svn简单好用。用了git之后,git真的更好用,不过刚开始用的时候,特别不懂怎么解决冲突问题,以及在分支合并的时候有点怕怕的,怕合并少了别人的代码,或者合并错分支等等。还有idea上的git我一开始也只会pull和push,对别的功能点也不懂。探索一下merge和rebase和冲突时的操作
merge的原理是找到这两个分支的祖先commit,在两个分支最新的commit进行三方对比合并
例如下图,共同的祖先commit2,master最新commit6,develop最新commit5,merge会基于2,5,6这三个commit进行对比
注:git会对每个文件进行一个哈希计算,这个值一样的话说明文件没有改动过
最后合并完后会生成一个新的commit7
图1
重新基于一个分支上进行commit,就是会把当前分支从祖先的commit后提交的commit都撤销掉,放到一个缓存里面去,然后基于一个分支的后面,把缓存的commit再按顺序一个个新增到这个分支后面
例如上图,在develop分支进行rebase master分支,则会把develop分支上的基于和master共同的祖先分支commit2的后面的commit4,5撤销掉,在master的最新的commit6后面重新增加commit4,5上去,这时候develop相当于在master最新的commit上逐步提交了两个commit4,5
这里新增了commit4
,5
,在merge时有可能都会有冲突,这里有可能需要手动merge两次,因为rebase时可能在提交commit4的时候提示冲突一次,在提交commit5的时候又冲突一次
图2
注:
我一般的做法,如果合并分支的共同祖先分支相差一两个或两三个commit的话,我就用rebase,毕竟rebase合并后好看,分支图谱明确,如果和共同祖先分支相差很多个commit,说明rebase有可能出现多次冲突,合并会很麻烦,这时候我就会用merge
同一个分支上,另一个提交了A文件的修改,这时候我也提交了A文件的修改,就会提示冲突
例如已经有同事修改了A文件,我也修改,commit保存在本地是没有问题的,但是当我推送的时候就会提示冲突,这时候可能处理的流程有三个
建议的做法是,在每次push之前,先点击pull,按第3点来处理
具体冲突操作:
当然如果不点击merge,rebase呢
如果点击rebase,则会也基于两个分支的祖先commit,把本地的commit都撤销掉,放入缓存,重新基于远程分支最新的commit上进行把本地撤销的commit一个个commit,中间有冲突则会提示merge(可能会有多个merge),好处是commit的log会好看很多,不会有提示合并过的痕迹。
当然如果也不点击merge,直接关闭掉呢
这样的话冲突的文件就会变红色,并且有>>>>>>标志其他版本的变更
这时候我们需在点一下解决冲突resolve conflicts,然后就相当于上面点的merge的效果了,看到合并代码的提示,然后再commit和pull到远程分支就可以了