Git工作流的分支管理的解决方案

本文为基于git-flow工作流机制摸索实践出的一套工作流管理流程。

1、分支名称及用途

• Master：初始分支及生产对应分支，配置库创建之初最先创建的分支。上线后，该分支代码版本始终与生产环境保持一致，保证生产环境代码可追溯；
• HotFix：临时分支，当生产发现紧急问题，基于master分支拉取hotFix分支进行紧急问题修复；
• Develop：长期的主开发基线，在该分支进行日常的开发及缺陷修复；
• dailyFix：日常版本发布基线，用于同步develop某一时点的版本，并基于该版本进行FAT、UAT发布验证；
• feature/dev1：某一时段的新需求开发分支，对应新需求验证环境；
• feature/dev2：某一时段的新需求开发分支，对应新需求验证环境；
• feature/dev…

2、分支生命周期及对应环境

• Master

Master始终存在，项目上线后总是与生产环境相对应。所有人员不能直接在master分支提交代码，只能从hotFix、dailyFix分支合并过来。合并时机为hotFix或dailyFix分支上线后的1-2天内。

• hotFix

只有当生产上出现紧急问题，需紧急修复时，基于Master拉取hotFix针对生产的问题进行修复，并在准生产环境进行验证，验证完成后发布到生产环境，发布完成后hotFix分支同步到master和develop分支。同步到master保证master分支对应生产环境代码版本，同步到develop将修复的缺陷在FAT、UAT进行后置验证并进入到以后的版本中。

• Develop

初始从master分支产生，一致存在，作为主开发基线，日常版本的FAT、UAT版本都从这里从某一个时点发起向dailyFix分支合并。

• dailyFix

日常FAT、UAT版本分支，每次版本分布时，需从develop分支将最新代码同步至dailyFix分支后，编译打包部署到FAT，待FAT验证通过，再进行编译打包到部署到UAT环境。

• feature/dev1、feature/dev2、feature/dev3……

周期性新需求交付开发分支，当有新需求是，基于develop分支创建feature/devx分支。该分支也有自己的日常新需求验证环境，新需求开发完成，会将该分支代码合并回主开发分支develop上，经FAT、UAT测试完成后实现交付。

注意：该分支根据功能、业务模块、交付批次创建多个分支，粒度划分尽量合理：尽量避免不同交付批次的新需求在一个feature分支上，造成该分支生命周期过长；尽量避免交付时一个分支中包含本次交付和下次交付的需求，造成人工进行分支合并（从中挑选本次交付的需求，人工合并到develop分支上，产生大量人工工作量）。

3、分支合并策略及时机

• Develop –> dailyFix

日常FAT、UAT版本发布分支合并。合并时机：每次dailyFix发送测版本前进行合并；

• dailyFix –> master

阶段发布生产版本进行的分支合并。合并时机：每次dailyFix对应版本送测完成并上生产后1-2天内进行合并；

• hotFix –> master

生产紧急缺陷修复发布分支合并。合并时机：每次紧急版本在准生产验证通过，并上生产后的1-2天内进行合并，并且要往develop进行一次合并，均合并完成后，及时删除hotFix分支；

• hotFix –> develop

生产紧急缺陷修复同步到主开发基线的分支合并。合并时机：hotFix  master完成后，同时完成hotFix  develop，并及时删除hotFix分支；

• dailyFix –> feature/devx

当有新需求时，基于当前的develop的送测分支拉取featrue分支，并在该分支上进行新功能、新需求的开发；

• Feature/devx –> develop

阶段性新需求交付分支合并（建议新需求交付日期前一段时间进行该合并，为新需求合并回主开发基线留出充足时间进行合并后的稳定性及缺陷相关验证）。

4、分支管理整体流程

分支管理相关概述图如上，相关步骤说明如下：
1） 项目初始只有一个master分支，基于master创建develop分支作为主开发基线；
2） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
3） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
4） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
5） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
6） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
7） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
8） 到达一个时点，进行生产上缺陷修复及需求交付，版本发布到生产；
9） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
10） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
11） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
12） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
13） 当生产发现紧急缺陷，基于生产版本对应的master分支创建hotFix分支，并在此分支上进行缺陷修复；
14） 紧急缺陷修复后再准生产环境进行版本验证，若为通过，重复步骤14进行缺陷修复及发布到准生产，直到缺陷完全修复并验证通过；
15） 缺陷修复并发布至生产环境后，将hotFix代码同步至master分支，保证master分支始终与生产环境保持版本一致；
16） 紧急缺陷修复代码同步至主开发基线develop分支，进行后置的FAT、UAT的验证，同时保证修复代码合并进以后的版本中；
17） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
18） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
19） 与行方评审完一批新需求，根据功能、业务模块、交付时间等不同维度将需求拆分为不同维度的小需求，对应多个feature分支；这些feature分支均基于主日常出版本基线dailyFix分支创建的；
20） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
21） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
22） 新需求开发人员在对应的feature/xxx分支上进行迭代开发，代码提交，Jenkins拉取feature/xxx本身进行版本编译，Jenkins编译版本期间，为保证编译成功tag推送成功，可通过gitlab的分支权限机制，禁止任何人推动代码到服务器，待编译并推送tag完成，开放该分支的代码推送权限，通过OMS部署到新需求验证环境进行FAT、UAT验证；
23） 新需求开发过程中需要定期将主开发基线的修复缺陷代码单向同步到新功能分支feature/xxx中，冲突在日常开发中解决，避免最终合并回develop分支集中解决冲突；
24） 新需求开发人员在对应的feature/xxx分支上进行迭代开发，代码提交，Jenkins拉取feature/xxx本身进行版本编译，Jenkins编译版本期间，为保证编译成功tag推送成功，可通过gitlab的分支权限机制，禁止任何人推动代码到服务器，待编译并推送tag完成，开放该分支的代码推送权限，通过OMS部署到新需求验证环境进行FAT、UAT验证；
25） 阶段性新需求开发及初步验证完成，合并到主开发基线develop分支，进行迭代验证，该合并策略存在两种分别如下：
a) 基于Git日志的自动合并策略；
b) 人工出去代码比对合并策略；
以上两种策略针对的情况不同：（a）策略为该feature/xxx分支上的所有新需求均要交付准备上线，该情况为出现较好的情况，基于Git自动的分支合并，人工解决少量冲突即可，较为省时省力；（b）策略为该feature/xxx分支上包含本次交付要上线的需求和由于突发因素不能上线的需求，该情况需要人工进行feature/xxx分支抽取代码到develop的合并，人工工作量大，且容易出现漏合（某个功能没有完全合并进来）及误合（合并中包含了本次不能上线的需求的代码）等问题。
26） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
27） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
28） 阶段性新需求交付合并回主开发基线迭代验证完成，合并到master分支准备发布到准生产验证完成通过后，发布到生产环境；
29） 基于当前主开发基线develop分支创建feature/xxxx分支，作为新一轮新需求（或上一轮遗留需求）开发分支；
30） 如有上一轮需求中的遗留需求，将之前合并进develop的分支再合并到新创建的feature/xxxx分支上，合并过程中的冲突解决策略为以新创建的feature/xxxx为准；
31） 新需求开发人员在对应的feature/xxx分支上进行迭代开发，代码提交，并发布到新需求验证环境进行FAT、UAT验证；
32） 新需求开发过程中需要定期将主开发基线的修复缺陷代码单向同步到新功能分支feature/xxx中，冲突在日常开发中解决，避免最终合并回develop分支集中解决冲突；
33） 新需求开发人员在对应的feature/xxx分支上进行迭代开发，代码提交，并发布到新需求验证环境进行FAT、UAT验证；
34） 参考（24），阶段性新需求开发及初步验证完成，合并到主开发基线develop分支，进行迭代验证，策略及选择同（24）；
35） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
36） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；
37） 阶段性新需求交付合并回主开发基线迭代验证完成，合并到master分支准备发布到准生产验证完成通过后，发布到生产环境；
38） 开发人员在主开发基线develop上进行日常缺陷修复，代码提交；
39） 日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；

注

• 1、开发人员在主开发基线develop上进行日常缺陷修复，代码提交；日常FAT、UAT版本发布前进行develop到dailyFix的代码同步；与大部步骤是并行进行的，也就是说在develop上进行缺陷修改及验证是长期的过程。
• 2、HotFix分支有生产紧急缺陷是创建，修复后删除该分支；
• 3、所有开发分支都从develop创建；
• 4、Develop分支上的代码都要整体上，在合并到develop分支前将不要上的需求滤掉；
• 5、dailyFix往feature同步问题
  如上流程图所示，develop定期同步到feature分支，考虑到及时将develop修复缺陷状态同步到新功能分支上，将合并冲突的工作分散到日常的同步中，减小最终的feature合并到develop集中解决冲突的人工工作。