前言
去一个新的公司一定要遵守的开发规范，肯定是分支管理规范了。如果你不弄清楚分支的管理规范，真的生产环境变发开环境。
今年团队招了不少人，进来之后没有负责人给你讲开发规范啥。所以有哪些规范你得主动问同事，今年有新同事直接把dev分支的代码合到master了。
说说常见的两种分支开发规范吧。
分支管理
常见主分支：
- dev （开发环境）
- test （测试环境）
- prepro（预生产、稳定环境）
- master（生产环境）
方式一：传统开发模式的git管理方式
代码拉取合并方式
-
迭代开始： 从dev环境拉去新的feature需求分支 ，功能开发完成后合到dev 开发分支 进行前后端联调；
-
测试：将dev分支代码合并到test
-
预生产：将test分支的代码合并到prepro
-
生产环境：将prepro 推送到master
这种git合并方式，就是不能同时开发两个版本，如果dev分支存在两个版本的代码，其中一个版本需要进入下一个阶段的话，另一个版本的代码也会被合并到下个环境的分支上，从而污染代码。
优点
管理的分支比较少，避免多个版本并行，使得代码在合并时只关注一个版本，减少合并代码解决冲突带来额外的工作量或者风险。比较利于版本控制或者说利于项目管理。
缺点
版本控制，不是很灵活，需要顺序开发版本
方式二、敏捷开发或者微服务开发（多版本并行开发）
代码拉取合并方式
- 迭代开始： 从master拉取新的feature需求分支，开发完成后将feature分支合并到dev分支进行联调；
- 测试：将feature分支合并到test分支
- 预生产：feature分支合并到prepro 分支
- 生产环境：feature分支的代码合并到master分支
优点
灵活性强，适合敏捷开发、微服务开发、版本经常不能自主把控的情况下。
微服务架构下：项目本身有需求在迭代，突然另一个项目的迭代需要你提供接口，如果采用 方式一 的分支管理，就需要等当前迭代结束之后了。如果是用的方式二，就能马上安排开发同步进行，甚至提前发版。
发版不可控：需求经常变动，不能自主控制发版时间（甲方要求），这种情况在小公司经常遇到，可能还在开发一个版本，就要立即修改之前发版的另外需求。使用并行开发的模式就能很好的应对这种情况
缺点
可能会存在多个版本在开发，版本控制，项目管理难度增加。多个版本合并冲突的情况增多。
注意： 在多版本并行开发过程中一定注意需求的解耦，不能存在两个版本的代码有先后问题，或者有互相依赖问题。有时候产品是无法把控这个问题，这就需要开发做好把控，想好解决方案。
