转载:git 冲突

** 转载地址 **:http://my.oschina.net/u/1757458/blog/349827

摘要

git conflict 通常有三种 树冲突、内容冲突、逻辑冲突。

冲突的产生

• 很多命令都可能出现冲突,但从根本上来讲,都是merge 和 patch(应用补丁)时产生冲突。
• 而rebase就是重新设置基准,然后应用补丁的过程,所以也会冲突。
• git pull会自动merge,repo sync会自动rebase,所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了

冲突的类型

1.树冲突

• 方法文件名修改造成的冲突,称为树冲突。
• 比如,a用户把文件改名为a.c,b用户把同一个文件改名为b.c,那么b将这两个commit合并时,会产生冲突。
• $ git status added by us: b.c both deleted: origin-name.c added 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提交即可。

2.逻辑冲突

• git自动处理(合并/应用补丁)成功,但是逻辑上是有问题的。
• 比如另外一个人修改了文件名,但我还使用老的文件名,这种情况下自动处理是能成功的,但实际上是有问题的。
• 又比如,函数返回值含义变化,但我还使用老的含义,这种情况自动处理成功,但可能隐藏着重大BUG。这种问题,主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
• 这种冲突的解决,就是做一次BUG修正。不是真正解决git报告的冲突。

3.内容冲突

• 两个用户修改了同一个文件的同一块区域,git会报告内容冲突。我们常见的都是这种。

冲突情况

• 当我们merge还是pull完后如果有冲突的话就会出现下面这个状态


出现CONFLICT 冲突我们就必须去查看对应的文件而不是直接add . 再次commit,这样git会直接把两个冲突的文件合并,然后提交

冲突处理

• 当两条分支对同一个文件的同一个文本块进行了不同的修改,并试图合并时,Git不能自动合并的,称之为冲突(conflict)。解决冲突需要人工处理。
• 比如当前在master分支,想把dev分支merge过来,结果产生了一个冲突,打开文件内容可以看到这么一个冲突:
• <<<<<<< HEAD
• test in master
• =======
• test in dev
• >>>>>>> dev

• <<<<<<<标记冲突开始,后面跟的是当前分支中的内容。
• HEAD指向当前分支末梢的提交。
• =======之后,>>>>>>>之前是要merge过来的另一条分支上的代码。
• >>>>>>>之后的dev是该分支的名字。
•   对于简单的合并,手工编辑,然后去掉这些标记,最后像往常的提交一样先add再commit即可。

git 删除已经 add 文件
使用 git rm 命令即可,有两种选择
• git rm --cached "文件路径",不删除物理文件,仅将该文件从缓存中删除;
• git rm --f "文件路径",不仅将该文件从缓存中删除,还会将物理文件删除(不会回收到垃圾桶)。

Git工作方法

• git branch working #建立一个自己的分支,如取名working
• git checkout working #确保使用的是工作分支
• git add .
• git commit -m"$1" -a #提交代码到本地,工作分支增加一个版本,这里的$1是运行脚本的第一个参数
• git checkout master git pull origin master #切换回默认分支,并将默认分支和中央最新版本合并
• git merge working #在本地合并你的这次修改到默认分支
• git push origin master #提交到中央版本库,接下来还是要切换回工作分支的
• git checkout working --force

推荐阅读更多精彩内容