具体开发模式
在公司中，master分支往往用于发布比较稳定的版本，而日常的开发都是基于dev进行的。目前较为常用的开发模式为：
1.每个人都从dev上拉取一个自己的分支进行开发，开发完成，确保没问题之后将自己的分支推送到远端；
2.由相应的负责人（也可能是你自己）将最近的修改整合到dev分支；
3.当一个迭代完成之后，会由开发组长来将dev分支的改动整合到master分支上。
基本使用篇就是基于这个背景下进行演示的，当时只是简单的完成了第一步，今天会写到合并分支的相关操作以及Git采用分支的原理。
分支操作
首先查看分支：
将dev分支的代码提交之后，需要与master分支合并，首先需要切换到master分支上：
$ git checkout master
然后我们将自己分支的结果合并到dev分支上：
$ git merge dev
在合并过程中可能会有冲突，进行解决之后再次提交即可。**Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。**疑惑的点出现了，我们每进行一次迭代就会伴随着Git分支的创建、合并、删除，在Git中的处理岂不是会很繁琐？
Git分支原理
其实Git管理项目版本是基于生命线来管理的，每一次提交都是这条线上的一个节点：
master分支其实就是一个指针，它指向了自己所处的版本；而HEAD指针则是代表当前分支的意思，表示当前分支为master分支。执行checkout -b dev之后，就会在master所指的位置再添加一个dev指针（dev后面可以指定具体的远程分支，表示从指定分支拉取）。
之后两个分支正常沿着各自的生命线走，当前分支（HAED）为dev分支。
需要将dev合并到master分支上时，需要解决相应的冲突，之后进行分支合并：
所以，在Git上进行分支操作时，涉及到的仅仅是引用的重新赋值，而不会导致太大的性能损耗。
