Git 分支管理与冲突解决
目录：
- Git 分支管理：本地分支、远程仓库分支
- 合并模式
- 冲突解决：本地冲突、推送冲突
Git 分支提供了并行工作的功能。 假设你准备同时学习 Git 和 SVN，你可以用两个分支分别来学习，完成之后进行合并，你就掌握了两种工具的使用了。 Git 和 GitHub 的基本操作可以参考我的这篇博客Git
和 GitHub 使用。
1. 分支管理
查看分支 git brance
创建分支 git branch dev # dev 是分支名
切换分支 git checkout dev
创建+切换 git checkout -b dev
合并分支 git merge dev #分支 dev 合并到 master
删除分支 git branch -d dev #已合并的分支
强行删除分支 git branch -D dev #分支未合并
查看分支图 git log --graph
远程仓库的分支
当你从远程仓库克隆时，实际上 Git 自动把本地的 master 分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
如果要在远程仓库的其他分支 (如 dev 分支)上开发，就必须创建远程
origin/dev 分支到本地：
git checkout -b dev origin/dev #创建远程仓库的分支到本地，必须先克隆或关联一个远程分支
本地分支和远程分支的名字最好一致。
推送成功之后, GitHub 上的 MyRepos 仓库 dev 分支上增加了一个文件。
2. 分支合并模式
- Fast forward 模式
默认模式，在这种模式下, 删除分支后，会丢掉分支信息，看不到合并记录.。并不是任何情况都能用这种模式。
- 普通模式
加上 --no-ff 参数就是普通模式。在普通模式下, Git 会在 merge 时生成一个新的 commit，这样从分支历史上就可以看出分支信息。
普通模式
快进模式
分支图
在分支图中, 红线是子分支 dev, 绿线是主分支 master. 子主分支分别提交了一次修改, 在将 dev 合并到 master 时发生冲突, 修改冲突文件内容之后再提交。
3. 解决冲突
如果两个分支都分别有了新的提交，Git 无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。必须手动解决冲突后再提交。git status 也可以告诉我们冲突的文件。
内容冲突
两个分支对同一文件的内容进行了修改并分别提交, 如果合并失败, 就必须手动解决冲突, 修改文件的内容之后再进行提交。
在冲突内容中, Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容. 文件的内容可以协商修改。
树冲突
一个分支修改了内容, 另个一分支删除了文件, 在试图合并时就会出现树冲突。假设子分支(如 dev)是要合并到主分支 master 的, 处理的方法有：
- 放弃 dev 的修改：强制删除 dev 分支, 然后提交即可。
- 放弃 master 的修改----分下面两种情况：
- master 修改了内容, dev 删除了文件： 在 master 分支中删除该文件, 然后提交；
- master 删除了文件, dev 修改了内容： 在 master 分支中添加被修改的文件, 然后提交。
master 修改了内容, dev 删除了文件：
master 删除了文件, dev 修改了内容：
对于文件的移动(在 Git 仓库目录范围内)和重命名, Git 都可以自动合并。
远程仓库推送冲突
从远程分支抓取最新的提交 git pull
建立本地分支与远程分支的连接 git branch --set-upstream dev origin/dev # dev 为分支名
如果推送出现冲突， 先将远程分支最新的提交抓取下来， 在本地解决冲突之后再推送。解决冲突的方法与本地冲突完全相同。
参考：
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013760174128707b935b0be6fc4fc6ace66c4f15618f8d000