首发公众号： 赵侠客
引言
作为开发者每天在写代码的同时也在写BUG，所以一方面需要开发新的需求，另一方面还要填自己以前挖的坑。目前主流程序员都在使用GIT来管理自己的代码，当GIT仓库有多人维护或者项目有多个版本同时迭代开发时，就需要有一套合理的GIT分支管理流程来维护自己的代码。一般企业级项目都是按版本来迭代的，每个版本之间可能并不是串行的，在业务快速发展阶段很可能会出现多版本并行开发的情况，以公司有三套环境（测试环境、预发布环境、生产环境）为例本文介绍一种简单的多版本、多人并行开发GIT分支管理规范，希望该GIT分支管理规范能对您的团队带来帮忙，同时因为每个公司开发人员水平和流程有差异如果觉得该规范有什么不合适地方也希望大家指出，可以一起探讨改进。
二、环境介绍
- 测试环境（dev）
为了简单我们没有拆分开发环境和测试环境，严格来说开发环境(dev)是做为开发者自己来Debug的一套环境，测试环境(test)是开发者完成需求开发后交付给测试人员验证的一套环境，为了方便快捷我们可以将这两个环境合成一个环境，当然这也因为开发人员频繁发版给测试人员带来测试环境不稳定的问题，还可能对测试人员回归BUG产生影响，可能回归好的BUG由于开发人员修改了代码又复现了。 不过既然是多版本并行开发，主要是以效率为主，开发和测试之前配合是非常重要的，好的配合是可以避免这些问题。
- 预发布环境(pre)
这套环境是模拟生产环境，在测试人员完成所有BUG回归后会将需要发版的代码部署到预发布环境，在这个环境需要将发版相关的配置、SQL脚本统一整理，为上生产做准备，这个环境基本上不会有因为代码层面产生的BUG，大都是由于配置、数据等问题引发的BUG。
- 生产环境(prod)
这个环境就是正式环境，发版就是将预发布环境的代码同步到该环境，同时当前版本在上预发布时记录的相关配置及SQL也一并在发版时同步到此环境。
三、开发流程
我们理想的开发流程可能是这样的
- 1.0.0版本需求评审
- 1.0.0版本代码开发
- 1.0.0版本提测
- 1.0.0版本上预发
- 1.0.0版本发版
- 1.0.1版本需求评审
- …
但是实现的开发流程并不是这样的，做需求的产品可能有好几个人，开发也会有好几个人，每个产品会根据自己的需求排一个独立的版本，然后按排对应的开发人员来完成该版本的开发。我们以同时开发1.0.0、1.0.1、1.0.2三个版本为例：
这三个版本可能是由三个产品经理来做的需求，每个需求由三个开发人员来完成，然后可能是不同时刻上测试环境，最后统一发版。当然也有可能有一个版本开发周期比较长，无法一起发版，也有可能在开发过程中间线上出线BUG了要单独修复，可能和当前版本一起发版，也可能因为BUG比较严重要立马修复，紧急上线。这些情况在实际开发过程中都是经常遇见的。所以针对这些情况必须有一套清晰的GIT分支管理规范，不然代码可能一团糟，也可能把没有测试过的代码发生产，造成不可预知的结果。
四、GIT分支管理
这套多版本并行开发的GIT分支管理规范主要分为5个：
- master，和生产环境正在跑的代码保持一致
- release，和预发布环境正在跑的代码保持一致
- dev，和测试环境跑的代码保持一致
- feature/dev_x.x.x，为x.x.x版本需求正在开发的代码，开发前从master拉取
- hotfix/bug_x，为线上x(Bug号) Bug修复的代码，修复前从master拉取
上图为同时开发1.0.1和1.0.2版本及修复线上BUG_1的GIT分支管理流程
- feature/dev_1.0.1，当完成1.0.1需求评审后，相关开发人员从Master拉取此分支进行开发
- feature/dev_1.0.2，当完成1.0.2需求评审后，相关开发人员从Master拉取此分支进行开发
- dev，在没有前置需求开发前从Master拉取
- 1.0.1提测，将feature/dev_1.0.1分支合并到dev，部署dev最新代码到测试环境
- 1.0.2提测，将feature/dev_1.0.2分支合并到dev，部署dev最新代码到测试环境，这步可能会产生代码冲突，这时谁开发的慢谁就要来解决冲突了🐶
- hotfix/bug_10000，可能线上出现了一个BUG，需要从Master拉取代码修复，修复完成合并dev，测试环境验证
- release，项管可能根据实际情况按排每个版本的发版窗口，1.0.1和1.0.2可能一起发，也可能单独发，还有可能和线上BUG一起发，我们根据实际情况，将需要发版的版本和BUG修复版本合并release，再次回归
- 发版，在release将验证过的版本打tag，交付运维人员上生产
- 完成发版后合并release到master，删除对应feature或者hotfix的开发分支
总结
本文介绍一种简单的多版本、多人并行开发Git分支管理规范，该方法为实际开发过程中总结的一套方法论，适用于项目快速迭代，需求更新频繁，发版窗口期比较短的业务场景，该方法主要有以下优点和缺点：
- 优点：
- 相对比较简单，不需要借助中间件来管理分支，完全由开发者手动管理分支与开发需求版本之前的对应关系
- 支持三套环境、多个版本多人同时开、及线上BUG修复等复杂业务场景开发
- 缺点：
- 上测试和上预发布都可能需要解决一次代码冲突，解决完需测试再次回归验证
- 发完版后release一定要合master，不然后面开发从master拉不是最新代码
