前言
本人的git项目分支管理借鉴了http://nvie.com/posts/a-successful-git-branching-model/ 这里的分支管理策略，但是有些区别。
正文
加上如上每条竖线代表一个分支，他有三个主要分支
develop分支 ：开发者在接到需求之后主要从事开发工作的分支。
release分支：测试在接到测试工作时主要使用的分支，在版本进入测试周期之后，会将该版本的测试代码从develop分支merge到release分支上，表示等待发布状态，此时将不会再添加新功能，只负责当前功能的bug修复。
master分支：当release分支上测试通过，表示代码随时能够发布时，会将代码merge到maste分支，并且打上tag，至此，该版本封版，所有发现的bug均视为线上bug。
另外还有两类次要分支
hotfix分支：该分支适用于存在热修复功能的开发系统，当发现线上bug之后，如果该bug可以使用hotfix进行修复的，就会在hotfix分支上修复，并且进行测试。测试通过后并入maste分支，并且打上tag号。
功能分支：功能分支是develop分支的辅助分支，将新功能在独立分支进行开发，开发完成后再并入develop分支。这样能够减少多人开发中，单个开发者由于新功能添加过程中修改代码对其他开发者造成的影响。
有几个需要注意的地方：
1. master分支永远是稳定的代码，未经测试的代码不得合并入master分支。该分支只负责发布，不负责开发以及bug修复。
2. 在版本开发完成之后，代码会合并入release分支进行测试。release分支的所有提交应该不包含新业务的开发，只包含当前需要发布版本的bug修复。
3. 线上版本出现问题分为两类，一类能用hotfix修复，我们会使用hotfix分支修复后合并入master并且打上tag，并且还需要将hotfix分支的修复内容merge到release或者develop分支上（如果在release上修复，需要记得合并到develop分支中）。还有一部分无法进行hotfix修复，这些bug的修复分支可以在release上，也可以在develop上（如果在release上修复，需要记得合并到develop分支中）。
4. 功能分支属于辅助分支，当新功能开发完毕并且合并入develop分支之后就逐渐失去作用，等到包含该功能的版本进入测试阶段，并入release之后，我们可以删除该分支，否则时间久了将会积累非常多的功能分支，反而不方便管理。
5. 有时候我们需要测试接入对功能模块的单独测试，所以测试可能直接使用功能分支代码进行测试，这时候的bug修复就需要在功能分支上进行修复。