冲突的类型
逻辑冲突
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: a.c
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 origin-name.c
git add b.c
git commit
执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。
树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。
最后执行git commit提交即可。
问题:
CONFLICT（content）：Merge conflict in XXXX/.DS_Store.
AutoMatic merge failed；fix conflicts and then commit the result.
冲突内容：合并冲突在 XXXX.DS_Store文件中
自动合并失败；修改冲突然后提交修改后的结果。
<<<<<<<< HEAD
你写的代码
===============
别人写的代码
>>>>>>>>>>>>>>> e4tghhhqd128dqwenasjdqasddcvbdgffg
解决:
首先先分析两个人的代码是实现相同功能而写的重复的代码,
还是各自实现的不同的功能的代码。
如果是重复代码：两个二选一删除一个，然后再把这些冲突标示符删除即可；
如果不是重复代码，两个都需要保留，只把冲突符号（红色部分）删除即可。
是自己的就保留自己的代码,
是别人的就保留别人的代码.
编译通过之后重新提交:
修改完成后：
1 git add . 将文件添加到暂存区
2 git commit -m “例如 完成了xxx功能的开发 (提交到本地仓库)"
3 git checkout xxx 切换到所开发的分支
4 git pull origin xxx 把服务器代码拉下和本地代码合并
( 注意先拉取在合并, 避免代码冲突 )
5 git merge xxx 合并自己的任务分支
6 git push origin xxx 把合并好的最新代码推送到服务器端