冲突的产生



很多命令都可能出现冲突,但从根本上来讲,都是merge 和 patch(应用补丁)时产生冲突。



而rebase就是重新设置基准,然后应用补丁的过程,所以也会冲突。



git pull会自动merge,repo sync会自动rebase,所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。



冲突的类型

逻辑冲突



git自动处理(合并/应用补丁)成功,但是逻辑上是有问题的。



比如另外一个人修改了文件名,但我还使用老的文件名,这种情况下自动处理是能成功的,但实际上是有问题的。



又比如,函数返回值含义变化,但我还使用老的含义,这种情况自动处理成功,但可能隐藏着重大BUG。这种问题,主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。



这种冲突的解决,就是做一次BUG修正。不是真正解决git报告的冲突。



内容冲突



两个用户修改了同一个文件的同一块区域,git会报告内容冲突。我们常见的都是这种,后面的解决办法也主要针对这种冲突。



树冲突



文件名修改造成的冲突,称为树冲突。



比如,a用户把文件改名为a.c,b用户把同一个文件改名为b.c,那么b将这两个commit合并时,会产生冲突。


$ git status
    
    added by us
    :    b.c
    
    both deleted
    :   origin
    -name.c
    
    added by them
    :


如果最终确定用b.c,那么解决办法如下:


rm a.c
    
git 
    rm origin
    -name.c
    
git add b.c
    
git commit


执行前面两个git rm时,会告警“file-name : needs merge”,可以不必理会。



 



树冲突也可以用git mergetool来解决,但整个解决过程是在交互式问答中完成的,用d 删除不要的文件,用c保留需要的文件。



最后执行git commit提交即可。



内容冲突的解决办法

发现冲突



一般来讲,出现冲突时都会有“CONFLICT”字样:

$ git pull
    
Auto
    -merging 
    test.txt
    
CONFLICT (content)
    : Merge conflict 
    in 
    test.txt
    
Automatic merge failed; fix conflicts 
    and 
    then

 



但是,也有例外,repo sync的报错,可能并不是直接提示冲突,而是下面这样:


: project mini
    /sample

注:无论是否存在冲突,只要本地修改不是基于服务器最新的,它都可能报告这个错误,解决方法都是一样。



 



这个时候,需要进入报错的项目(git库)目录,然后执行git rebase解决:



-branch
    -name



冲突解决的一般过程

merge/patch的冲突解决



先编辑冲突,然后git commit提交。



注:对于git来讲,编辑冲突跟平时的修改代码没什么差异。修改完成后,都是要把修改添加到缓存,然后commit。



rebase的冲突解决



rebase的冲突解决过程,就是解决每个应用补丁冲突的过程。



解决完一个补丁应用的冲突后,执行下面命令标记冲突已解决(也就是把修改内容加入缓存):



-u



注:-u 表示把所有已track的文件的新的修改加入缓存,但不加入新的文件。



 



然后执行下面命令继续rebase:



-- continue



有冲突继续解决,重复这这些步骤,直到rebase完成。



 



如果中间遇到某个补丁不需要应用,可以用下面命令忽略:



--skip



 



如果想回到rebase执行之前的状态,可以执行:



--abort



 



注:rebase之后,不需要执行commit,也不存在新的修改需要提交,都是git自动完成。



编辑冲突的方法

直接编辑冲突文件



冲突产生后,文件系统中冲突了的文件(这里是test.txt)里面的内容会显示为类似下面这样:



a123
   
<<
   <<
   <<
   < HEAD
   
b789
   
==
   ==
   ==
   =
   
b45678910
   
>>
   >>
   >>
   > 
   6853e5ff961e684d3a6c02d4d06183b5ff330dcc
   
c


其中:冲突标记<<<<<<< (7个<)与=======之间的内容是我的修改,=======与>>>>>>>之间的内容是别人的修改。



此时,还没有任何其它垃圾文件产生。



 



最简单的编辑冲突的办法,就是直接编辑冲突了的文件(test.txt),把冲突标记删掉,把冲突解决正确。



利用图形界面工具解决冲突



如果要解决的冲突很多,且比较复杂,图形界面的冲突解决工具就显得很重要了。



 



执行git mergetool用预先配置的Beyond Compare解决冲突:

$ git mergetool
    
Merging
    :
    
test.txt
    

Normal merge conflict 
    for 
    'test.txt'
    :
    
  {local}
    : modified
    
  {remote}
    :


 




Git下的冲突解决_解决冲突


 


上面三个窗口依次是“LOCAL”、“BASE”、“REMOTE”,它们只是提供解决冲突需要的信息,是无法编辑的。


下面一个窗口是合并后的结果,可以手动修改,也可以点击相应颜色的箭头选择“LOCAL”或者“REMOTE”。


 


在Beyond Compare中修改冲突保存后,冲突文件(test.txt)中的冲突标记就没有了,成了修改后的内容,一个文件的冲突编辑就完成了。


 


注意:


启动Beyond Compare之后,会自动生成几个包含大写字母名称、数字的辅助文件:



Git下的冲突解决_冲突解决_02


 


关闭Beyond Compare时,这几个辅助文件都会自动删除,但同时会生成一个test.txt.orig的文件,内容是解决冲突前的冲突现场。


默认该.orig文件可能不会自动删除,需要手动删掉。