愿所有美好如期而遇
目录
理解分支
创建分支
切换分支
合并分支
删除分支
合并冲突
分支管理策略
理解分支
每次提交master都会前进一步，随着不断提交，master分支的线越来越长，而HEAD指向哪条分支就是当前工作的分支。
master分支是我们创建本地仓库时系统默认创建的分支。
创建分支
git branch 查看当前所有分支
这个*表示HEAD指向的分支，也就是我们当前工作的分支
git branch name 创建一个新的分支
我们发现新建的dev分支与master分支都指向最新的提交
切换分支
那么如何切换到dev分支下进行开发呢?
git checkout 分支名字
现在我们在这个分支下对文件进行修改，添加一句话“分支dev”
添加并提交
现在我们切换回master分支，看看master分支有没有被影响。
没有受到任何影响，我们再来看他们的指向
发现指向已经不同了。
我们要想在master分支上看见dev上的提交怎么办呢？--->合并分支
合并分支
为了能在master分支上看见dev分支上的提交，我们需要将dev分支合并到master分支上。
git merge 分支名
需要注意的是，要将dev分支合并到master分支上，需要先切换到master分支上 。
Fast-forward模式，快进模式，合并时，master直接指向dev的当前提交
我们还可以来看看他的视图。
当然，也不是每次合并时都能使用快进模式，我们后面会说到其他的合并方式。
删除分支
在我们合并了dev分支后，dev分支也就没用了，所以我们删掉他
git branch -d 分支名字
我们已经完成了合并，所以此时删除分支时可以的。
合并冲突
在实际分支合并时，并不是每次都能合并成功的，有时候会遇到代码冲突的问题
我们创建一个新的分支并切换至该分支
git checkout -b 新的分支名字 一条指令一步到位
再切换至master分支做修改。
两个分支都对原有旧版本代码做了修改并提交，现在我们将newdev与master合并
这些符号之间的代码就是冲突的代码，我们只能手动去除冲突，保留一个
再次添加提交
我们此时的模式是--no -ff，也就是非快进模式
接着，我们删除分支
分支管理策略
通常我们合并分支时，如果可能，编译器通常会采用fast-forward模式，合并后结果是这样
master直接指向dev指向的最新提交。
但在合并冲突部分，我们也看到通过解决冲突问题，会在进行一次添加提交，得到的最终状态是：
这样的好处是，从分支历史上就可以看出分支信息。
我们已经删除了dev和newdev分支，但是我们仍然可以看到他们的过往信息，尽管我们删除了newdev分支，但是我们仍然可以看到现在的master分支是由其他分支合并而得到的。
编译器支持我们强制禁用fast-forward模式，那么在merge时会生成一个新的commit，这样我们就可以从分支历史上看出分支信息。、
我们再次新建一个分支测试--no -ff模式的合并
别忘了切换到master分支
所以在合并分支时，加上--no-ff参数就可以用扑通模式合并，合并后的历史有分支，能看出来做过合并，而fast-forward模式就看不出来曾经做过合并。
