有不少开发者们不习惯使用Git分支开发。原因有如下几个方面?
(1)不熟悉不习惯;
(2)觉得太麻烦;
今天我想说的是使用git分支开发绝对是一个高效版本控制的做法。

当你遇到测试人员给你提的bug，你只需将其pull下来，并执行git checkout -b bug-solution01该命令即可，这条命令是切换并创建分支，当你切换到创建的分支时，便可以着手解决对应的bug，解决这个bug后，然后执行git checkout master后，再执行git merge bug-solution01该命令合并分支即可。
不过在一些中大公司里面，它们并不会通过主分支来合并侧分支，而是有一个开发分支，通过开发分支合并开发者分支，最后通过持续集成使master分支和开发分支合并集成测试部署(其实也是可以手动切换到master分支合并开发分支)等。假设有A、B、C等三个开发者，通常分支的形式是这样:

• 主分支(master)
• 开发分支(project-dev)
• 开发者分支(A开发者分支、B开发者分支、C开发者分支等)

假设我是开发者A，测试给我提了一个bug，我在A分支的基础上创建一个解决bug分支(暂且命名为a-bug-solution)，当我在a-bug-sllution分支上解决了这个bug并git commit提交到本地仓库后，然后通过git log查看对应的日志(防止提交失败或者其它意外),查看有对应的提交记录后，然后我切换到a-project-dev分支上执行git merge a-bug-solution，合并该分支，合并该分支成功后，然后我再次切换到project-dev分支上，执行git merge a-project-dev进行合并，合并成功后，我就可以不管了，因为剩下的可以交给持续集成工具(jenkins等)。

上述说起了，大家可能觉得很麻烦或者是没必要这样做，原因可能觉得太耽误时间了，我的回答是非也，一开始可能有点麻烦，越到后面你会越发现它的好处，让你情不自禁地爱上它。

分支开发的好处，是真正的确保每个人有自己的独立分支而不是全部在master分支上开发，全部在master分支上开发，弊端太多，比如隔离性太差了，而且全部在一个分支上开发的话，经常面临的就是解决冲突(在自己的分支上开发进行合并与全部在一个主分支上开发进行对比，如果代码提交相对频繁，你将会发现你永远都在解决冲突，如果提交缓慢的话，你还是发现在解决冲突，实际上你并不需要解决太多冲突，很多冲突是没有必要的)。

最后归纳总结一下，分支开发的好处:

• 版本迭代更加清晰
• 开发效率提升
• 利于代码review的实现，从而使整个团队开发更加规范，减少bug率