序
现在到网上搜GIT关键字，结果往往是GIT命令大全。命令都会，但是提交代码时往往该出问题的时候还是会出问题。本文将结合我的经验，提出一些GIT分支的管理办法，希望对大家有些许帮助。
如果工程项目不分环境（正式，灰度，测试，开发），或者开发人员在三人以下，Windows用户请点击右上角，Mac用户请点击左上角。
准备工作
创建
我们按照一个普通的工程来进行初始化，创建若干分支：
PRO，Production environment，正式服
UAT，User Acceptance Test environment，灰度
FAT，Feature Acceptance Test environment，测试
DEV，Development environment，开发
分支作用顾名思义，不再展开。
分支保护
以gitlab为例，创建分支保护规则：
Settings -> Repository -> Protected Branches，选择PRO（Master）分支，指定Allowed to merge为TL（技术领导），Allowed to push为No one，或者TL。
那为什么不允许push PRO分支呢？
在多人开发项目中，merge和push是最容易覆盖别人代码的操作。PRO分支只允许储存线上运行的代码。如果开放了push，merge权限，那谁都可以向这个分支提代码了，这其实是很危险的！毕竟系统运行中最大的bug是人。
收归merge，push权限还有一个重要作用，让TL充分了解工作进度，顺便view代码。
开发分支命名
这是我在实践中践行的约定，大家可以参考一下：
自己的开发分支命名规则：开发者名工程名模块名
例：zhaomm_project_name_user_module
分支管理
理想的开发流程
其中，UTA -> PRO这一步，由开发人员在gitlab上发起merge request，由TL从UAT合并到PRO，上线后，开发人员可删除自己的开发分支。
当然啦，理想是美好的，现实是骨感的。来看看以下一些特殊情况怎么来处理：
多功能并行开发
有部分代码不会在下一次发布到正式服。
由于要发布的和提前开发的分支共用了FAT环境，所以FAT就不能直接合并到UAT了。
测试通过后，要发布的分支直接合并到UAT，最后再合并到PRO。
提前开发的分支，需要在上线后，合并PRO的代码。
随着容器技术的发展，现在环境和代码部署也越发简单，如果公司有能力的话，完全可以为每一个分支创建一个虚拟环境。但需要注意，每次上线后，都需要将PRO代码合并到接下来的开发分支中去。
正式服bug修复重上线
有时候，已经上线的代码需要紧急修改。
一般这种情况比较紧急，代码写好后，直接合并到FAT，交给测试。
测试通过后，直接把bug修复分支合并到UAT，避免FAT不上线的代码被合并到PRO。
上线后，将PRO代码合并到正常的开发分支中去。
最后
说了这么多，其本质就是解决，哪些代码要发布，哪些代码不发布的问题。
希望本文能对你有所启发。谢谢。
