慕仰0522570

冲突的产生很多命令都可能出现冲突，但从根本上来讲，都是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 statusadded by us: b.cboth deleted: origin-name.cadded by them: a.c如果最终确定用b.c，那么解决办法如下：git rm a.cgit rm origin-name.cgit add b.cgit commit执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。最后执行git commit提交即可。内容冲突的解决办法发现冲突一般来讲，出现冲突时都会有“CONFLICT”字样：$ git pullAuto-merging test.txtCONFLICT (content): Merge conflict in test.txtAutomatic merge failed; fix conflicts and then commit the result.但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：error: project mini/sample注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。这个时候，需要进入报错的项目(git库)目录，然后执行git rebase解决：git rebase remote-branch-name冲突解决的一般过程merge/patch的冲突解决先编辑冲突，然后git commit提交。注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。rebase的冲突解决rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决(也就是把修改内容加入缓存)：git add -u注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。然后执行下面命令继续rebase：git rebase --continue有冲突继续解决，重复这这些步骤，直到rebase完成。如果中间遇到某个补丁不需要应用，可以用下面命令忽略：git rebase --skip如果想回到rebase执行之前的状态，可以执行：git rebase --abort注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。编辑冲突的方法直接编辑冲突文件冲突产生后，文件系统中冲突了的文件(这里是test.txt)里面的内容会显示为类似下面这样：a123<<<<<<< HEADb789=======b45678910>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dccc其中：冲突标记<<<<<<< (7个>>>>>>之间的内容是别人的修改。此时，还没有任何其它垃圾文件产生。最简单的编辑冲突的办法，就是直接编辑冲突了的文件(test.txt)，把冲突标记删掉，把冲突解决正确。