说说实际开发中合并代码的方式吧

前言

去一个新的公司一定要遵守的开发规范，肯定是分支管理规范了。如果你不弄清楚分支的管理规范，真的生产环境变发开环境。

今年团队招了不少人，进来之后没有负责人给你讲开发规范啥。所以有哪些规范你得主动问同事，今年有新同事直接把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分支

优点

灵活性强，适合敏捷开发、微服务开发、版本经常不能自主把控的情况下。

微服务架构下：项目本身有需求在迭代，突然另一个项目的迭代需要你提供接口，如果采用 方式一 的分支管理，就需要等当前迭代结束之后了。如果是用的方式二，就能马上安排开发同步进行，甚至提前发版。
发版不可控：需求经常变动，不能自主控制发版时间（甲方要求），这种情况在小公司经常遇到，可能还在开发一个版本，就要立即修改之前发版的另外需求。使用并行开发的模式就能很好的应对这种情况

缺点

可能会存在多个版本在开发，版本控制，项目管理难度增加。多个版本合并冲突的情况增多。

注意： 在多版本并行开发过程中一定注意需求的解耦，不能存在两个版本的代码有先后问题，或者有互相依赖问题。有时候产品是无法把控这个问题，这就需要开发做好把控，想好解决方案。