标签：style http ar color os 使用 sp for strong
冲突的产生
? 很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。
? 而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。
? git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了
冲突的类型
树冲突
? 方法文件名修改造成的冲突，称为树冲突。
? 比如，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.c
git rm origin-name.c
git add b.c
git commit
? 执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。
?
? 树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。
? 最后执行git commit提交即可。
逻辑冲突
? git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
? 比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
? 又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
? 这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。
内容冲突
? 两个用户修改了同一个文件的同一块区域，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 "文件路径"，不仅将该文件从缓存中删除，还会将物理文件删除（不会回收到垃圾桶）。
标签：style http ar color os 使用 sp for strong
原文地址：http://my.oschina.net/u/1757458/blog/349827
