** 转载地址 **：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
