实用分支管理策略

首先挂一张分支管理策略的图（看不清点大图）

分支介绍

这里面一共有6个远程分支，分别是master分支，release分支，feature分支，dev分支，SIT分支，UAT分支。

• master分支：主分支，包含所有开发特性的，最全面的一个分支，分支存活期为永久。
• release分支：投产版本分支，包含所有投产特性的分支，分支存活期为永久。
• feature分支：迭代特性分支，在迭代开始时，迭代规划决定本次开发的功能点，每个功能点细化为一个feature分支，该分支上的每次commit为实现该feature的一个具体子功能，每次commit会触发一次CI，分支存活期为永久。
• dev分支：开发测试分支，主要用于feature分支迁移至dev分支时，进行CodeReview，代码评审过后会在该分支上进行CD，分支存活期为当前整个迭代，随着功能点合入master或者release而撤销。
• SIT分支：集成测试分支，条件允许的公司，有自己专门的测试团队，会从这上面拉取代码进行SIT测试，或者从刚才dev分支CD后的制品库拉取介质包，进行测试，分支存活期为永久。
• UAT分支：用户验收测试分支，SIT通过后，代码会合入UAT分支，测试团队从这个分支上拉取代码进行编译，或者从制品库获取介质包，在UAT环境进行投产前预演，分支存活期为永久。

分支关系

1、为什么要设置master 和 release这两个重复的分支？

• master分支存放所有代码，包含所有的功能点，而release分支存放所有投产的功能点，两者关系是：release是master的子集，release有的，master都有，master有的，release不一定有。
• 那么为什么会出现这种情况呢？因为有些功能点开发出来后，不一定投产，会等到某个时机，从master上分离这部分代码，打成patch合入release进行投产。

2、feature 和 dev是否重复了？

• 不重复，feature分支的存在，是为了梳理功能点，如果若干功能点在一个分支开发，commit会显得很乱，但是独立成一个分支，这些commit是在该分支上是连续提交的，无论是回退、打patch还是merge，都能很方便找到。
• 从功能上说，单个feature开发，影响范围小，降低了代码提交时与其他feature代码的冲突风险，而且每次提交只会触发本分支的CI，较少导致CI排队，效率较高。
• dev分支的存在，是为CodeReview量身定做的，即使CI和门禁都过了的代码，也有优化的潜力，工具检测是无法代替功力深厚的老架构的。

3、dev分支既然已经生成target介质，直接投产测试就好了，为什么还需要SIT和UAT分支？

• 测试规模不同：

  • dev在本组内进行测试，是组内开发的所有功能联合测试，看看这部分代码是否影响了其他人开发的功能，范围较小。
  • SIT是集成测试，这个时候涉及到所有组件联调，范围适中。
  • UAT是最关键的测试，仿生产环境进行测试，从测试流量和测试频率来说，都是最高的，也是最接近生产的，范围较大。

• 代码冲突：

  • feature分支合并时的代码冲突在合入dev时解决。
  • 在dev、SIT、UAT中发现问题，及时回到feature分之修复，再逐级提交，越早发现bug和冲突，代价越小。

有其他问题欢迎留言，要是项目组开发的不是微服务，或者代码量较少，完全没必要建立这么多分支，记住一句话：拉分支一时爽，销分支火葬场。