作者：京东科技 周新智
近日，IoT 研发团队加入了不少新同学，对 git 分支的命名和管理方式有些许的模糊，分支的命名规范以及管理方式对项目的版本发布至关重要，为了解决实际开发过程中版本发布时代码管理混乱、冲突等比较头疼的问题，我们将在文中阐述如何更好的管理代码分支。
• master: 主分支，也称为线上分支，主要用来版本发布。
• dev：日常开发分支，该分支正常保存了开发的最新代码。
• release：release 分支可以认为是 master 分支的测试版。比如说某个新增功能开发完成、线上问题紧急修复完成，那么就将 feature/hotfix 分支合并到 release 分支，到了发布日期就合并到 master 分支，进行版本发布。
• feature：具体的功能开发分支。
• hotfix：线上 bug 修复分支。
主分支包括 Master Branch、Release Branch、Dev 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 分支上，并择机进行线上发布。
dev 就是我们的日常开发分支。
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 分支。
顾名思义，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 分支进行代码同步。
通过以上分支管理，我们就可以轻松做到：团队成员之间功能并行开发、功能选择性发布、版本发布、线上问题紧急功能开发、紧急问题修复等。
