1.冲突
产生冲突后，查看readme.txt 可以看到冲突内容
<<<<<<<
=======
>>>>>>> 然后要同其他人商讨保留哪个。
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
用git log --graph命令可以看到分支合并图。
2. 分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
3.多人策略
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上
$ git push origin master
并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支
多人协作时，大家都会往master和dev分支上推送各自的修改。
1.当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。
2.创建本地dev分支 $ git checkout -b dev origin/dev
3.设置dev和origin/dev的链接：
$ git branch --set-upstream dev origin/dev4.提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
多人协作的工作模式通常是这样：
首先，可以试图用
git push origin branch-name推送自己的修改；如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并；如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用
git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。
小结
查看远程库信息，使用
git remote -v；本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用
git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name；从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。