作者：京东科技 周新智
一、引言
近日，IoT 研发团队退出了不少新同学，对 git 分支的命名和治理形式有些许的含糊，分支的命名标准以及治理形式对我的项目的版本公布至关重要，为了解决理论开发过程中版本公布时代码管理混乱、抵触等比拟头疼的问题，咱们将在文中论述如何更好的治理代码分支。
二、总览
从上图能够看到次要蕴含上面几个分支：
• master: 主分支，也称为线上分支，次要用来版本公布。
• dev：日常开发分支，该分支失常保留了开发的最新代码。
• release：release 分支能够认为是 master 分支的测试版。比如说某个新增性能开发实现、线上问题紧急修复实现，那么就将 feature/hotfix 分支合并到 release 分支，到了公布日期就合并到 master 分支，进行版本公布。
• feature：具体的性能开发分支。
• hotfix：线上 bug 修复分支。
三、主分支
主分支包含 Master Branch、Release Branch、Dev Branch 三个分支：
1、Master Branch
用来进行版本公布，也就是当火线上运行的代码分支
2、Release Branch
Release Branch 在我看来就是 Pre-Master。Release Branch 从 Master Branch 检出，最终会合并到 Master Branch，合并后 Master Branch 上就是能够公布的代码了。
所有新增性能的开发分支都是从 Dev Branch 检出作为本地分支，以 feature- 性能名 - 姓名首字母简拼，当性能开发结束的时候，将 feature Branch 合并到 Dev Branch，在测试或预生产环境进行部署，测试通过后，再将 feature Branch 合并到 Release Branch。
如果呈现线上问题须要紧急修复，则从 Release Branch 检出作为本地分支，以 hotfix- 性能名 - 姓名首字母简拼，当问题修复结束的时候，将 hotfix Branch 合并到 Dev Branch，在测试环境进行部署，测试通过后，再将 hotfix Branch 合并到 Release Branch，在预发环境再次验证。
待所有的测试和筹备工作做完之后，咱们就能够将 release 分支合并到 master 分支上，并择机进行线上公布。
3、Dev Branch
dev 就是咱们的日常开发分支。
四、辅助分支
1、Feature 分支
feature 分支用来开发具体的性能，个别 fork 自 Dev 分支，以 feature- 性能名 - 姓名首字母简拼 进行命名，最终合并到 Dev、Release 分支。比方咱们要在下一个版本减少性能 1、性能 2、性能 3。那么咱们就能够起三个 feature 分支：feature-1-zxz，feature-2-qxh，feature-3-sq。（feature 分支命名最好可能自解释，1、2、3 这并不是一种好的命名）随着咱们开发，性能 1 和性能 2 都被实现了，而性能 3 因为某些起因实现不了，那么最终 feature-1-zxz 和 feature-2-qxh 分支将被合并到 Dev 分支，而 feature-3-sq 分支将延期持续进行本地开发工作，性能 1 和性能 2 测试完没有问题后，将 feature1 和 feature2 分支将被合并到 Release 分支，最终将 Release 分支合并到 Master 分支。
2、Hotfix 分支
顾名思义，hotfix 分支用来修复线上 bug。当线上代码呈现 bug 时，咱们 基于 Release 分支开一个 hotfix 分支，以 hotfix- 性能名 - 姓名首字母简拼（例如：hotfix-model-base-zxz），修复 bug 之后再将 hotfix 分支合并到 Release 分支，同时 Dev 分支作为最新最全的代码分支，hotfix 分支也须要合并到 Dev 分支下来，同时在不同分支对应的不同环境进行 bug 回归验证，最终将 Release 分支合并到 Master 分支，进行线上公布即可。
五、注意事项
1、Feature 分支、Hotfix 分支合并到 Dev 分支，测试通过后，需再合并到 Release 分支，这时候就要求代码合并时需分明的晓得此代码是否曾经通过验证。
2、Dev、Release、Master 分支的同步
Release 分支合并到 Master 分支后，若 Dev 分支无正在测试的性能，倡议定时将 Dev、Release、Master 分支进行代码同步。
通过以上分支治理，咱们就能够轻松做到：团队成员之间性能并行开发、性能选择性公布、版本公布、线上问题紧急性能开发、紧急问题修复等。