git 版本控制的入门操作（五）------ 分支冲突、分支管理策略、bug分支
git 版本控制的入门操作（一）------ 安装、加入、提交、回退
git 版本控制的入门操作（二）------工作区、版本库、管理修改、撤销修改
git 版本控制的入门操作（三）------ 对比文件的不同、删除文件
git 版本控制的入门操作（五）------ 分支冲突、分支管理策略、bug分支
分支冲突
如果两个分支都修改了文件code.txt，并加入提交，那么怎么合并呢？
可以看出双方都修改了code.txt起了冲突。解决办法如下：
git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存
使用git log 查看合并的过程：git log --graph --pretty=oneline
这里有版本名的重复问题，不过用版本号是可以区分的。
分支管理策略
通常，合并分支时，如果可能，git会用fast forward模式，但是有些快速合并并不能成，这个时候会合并之
后并做一次新的提交。但这种模式下，删除分支后，会丢掉分支信息。
出现如下的情况这是因为这次不能进行快速合并，所以git提示输入合并说明信息，输入之后合并内容之后git会自动
创建一次新的提交。
你可以输入合并之后的版本名，然后离开。使用分支命令查看分支信息
注意观察Merge branch 'dev'版本，就是上面的这种情况，master分支是版本四，dev分支是dev版本,合并
之后出现上面的情况，我默认了离开取消，所以名字是默认的。
上面的内容可能你觉得麻烦，当然你也可以使用命令默认禁止使用快速合并：
git merge --no-ff -m '版本名' dev
Bug 分支
在git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，
然后将临时分支删除。
git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。可用于手头工作
还没有结束，但是必须马上去修复Bug。比如我现在在dev分支上工作，任务还没有完成，但是我要去修复Bug了。
则先stash手头工作，再去出Bug的分支创建一个bug分支。
回到工作分支如何继续工作呢？可以使用：git stash pop
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；当手头工作没有完成时，先把工
作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
