git是非常优秀的项目代码版本管理工具，但是在实际开发过程中，如果分支划分不合理，对分支管理起来依旧很吃力，按照我的实际经验，进行了如下总结：
master 主分支
正式环境代码，开过过程中要限制开发人员不能对改分支进行提交、合并操作，master的代码只能从uat分支合并过来，合并也只能由指定人员进行。
uat 预发布环境分支
对应预发布环境，项目需要上线时，要现在预发布环境中进行最后测试，改分支代码也不允许开发人员进行提交、合并操作，uat的代码只能从test分支合并过来，合并也只能由指定人员进行。
test 测试分支
对应测试环境，主要用于项目提测给测试部门进行测试时，采用test分支构建测试环境，test分支代码可以由dev分支合并或者fix分支合并过来，由专人负责。
fix 线上 bug 修复分支
当发现正式环境有bug需要修复时，但是实际dev分支上又在开发下一个版本的功能，这部分功能是不能发布上线的，那么这个时候就需要用到fix分支了，将master分支的代码合并到fix分支中，在fix分支上修复好bug，然后将fix分支的代码合并到test分支进行测试，当dev有下个版本功能也在测试时，就不会产生测试冲突。待测试通过后，fix的分支代码由test分支合并到uat分支最后合并到master分支进行发布，然后还需要将fix分支的代码合并到dev，保证新版中也修复了改bug。
dev 开发分支
这个分支存放开发的最新代码，然后基于改分支给每个开发人员创建自己的一个分支用于开发他们自己的内容，每次开发的开发人员只提交代码到自己的分支，然后定期或者有提测需求时，将各个子分支的代码合并到dev，尽量将所有开发的代码合并操作放在dev上进行，因为在本地合并时，dev分支是没有代码变动的，合并如果存在无法解决的冲突或者其他异常，直接放弃合并就行，如果在dev1分支中合并dev2的代码，dev1分支在合并之前需要先将自己的代码推送带远端dev1，保证在合并时出现问题后可以直接放弃合并，不然需要手动拆解自己的代码和合并过来之后的代码，很是麻烦；尽量要求每个开发人员每天早上拉取一遍dev分支的代码，减少冲突的可能性。
以上是我自己的一些总结，基本能满足日常开发中的大部分场景，如有不合理的地方，请各位大神指出，我及时修改。
