最新更新：冒烟提测后的一轮、二轮测试阶段，由开发在各自需求分支上打包提供给测试，目前根据项目会生成T型小组，由开发各自负责一个平台的打包，团队成员逐渐形成习惯，很少在合代码上出现问题。

git工作流

引言

工作流英文名称叫做“workflow”，高效的工作流能像流水一样让这个工作体验顺畅且自然。对于一个团队来说，如果没有制定规范有效的工作流程，那么必定会导致混乱与低效，甚至会影响到团队整个凝聚力与战斗力，更有甚者，会直接导致人员的流失与任务延期。在日常的代码开发中，我们不可避免的会使用到版本管理工具，目前最常用的代码版本管理便是git，制定一套规范有效的git工作流来规范我们的分支管理和工作流程是极其必要的，并且越早越好。

现有的广泛使用的git工作流

现在已经存在很多广泛使用的git工作流，最常见的是git flow、github flow、gitlab flow，下面是这些git工作流的对比。

	git flow	github flow	gitlab flow
简介	最早诞生、并得到广泛采用的一种工作流程	是git flow的简化版，专门配合“持续发布”，是github使用的工作流程	是git flow与github flow的综合
特点	1.存在两个长期分支，主分支master和开发分支develop 2.存在三种短期分支，功能分支、补丁分支、预发布分支	只有一个长期分支（master）	它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利，它是gitlab推荐的做法
优缺点	清晰可控、相对复杂	简单，但通常一个主分支不够用	清晰可控、简单

git工作流制定的目标是为了提高团队效能，对于无线前端团队来说，现有广泛使用的git工作流并不能完全适用在实际的需求开发场景中，所以需要根据自己团队特性来定制一套规范且有效的git工作流，命名为git-mango。

git-mango

git-mango是根据需求驱动设计的一套git工作流，主要包含分支管理和git工作流程管理两个部分。

团队及项目特性

敏捷开发，航班制进行版本发布
混合型开发，APP项目涉及到android、ios、rn、rn-web
分支集成Jenkins进行自动打包和rn-web构建

为了解决的问题

对于开发人员，提高代码管理的效率与安全性
对于测试人员，避免产生版本混乱和需要重复校验的情况，降低测试成本
对于分支管理人员，利于管理分支与观察分支，保证项目代码的稳定性与安全性
对于这个需求开发中的团队，在项目周期中提供顺畅的git工作流，自然无阻

分支管理

git-mango中的分支管理部分将所有的分支分为三类，分别为双主分支、特性分支和HotFix分支。分支管理首要解决的问题便是对于目前所有的分支进行规范，规范各分支的职责、操作权限及命名，如果职责和权限都不确定的话必定导致使用混乱，代码版本的稳定性被破坏。

双主分支

双主分支包含发布分支（master）和提测分支（sit），双主分支是一直跟随着项目周期的，并且任何时候线上代码仓库中都会保存这两个分支。

发布分支（master）用于存放对外发布的版本，在任何时候拿到的都是稳定的版本，不允许在该分支上开发代码，只允许提测分支（sit）和热修复（hotfix）分支提交代码合并。发布分支的名称不允许重命名，通常以master作为名称。

提测分支（sit）是开发完成后的提测分支，当需求开发完成且冒烟测试通过后便可以提交代码到sit分支。在sit分支上，还集成了Jenkins自动打包和rn-web构建等其他测试可用的功能。提测分支的名称也不允许重命名，可以用sit命名。

特性分支

特性分支又叫做需求开发分支，作为需求开发使用的分支，在启动新需求开发时都会从master拉出一个最新的需求开发分支，只存在于一个版本需求开发周期中，成功上线即删除分支。特性分支的命名以dev_开头，后面拼接具体的子需求名称，例如dev_pay支付需求的开发分支，如果一个版本上线存在多个子需求，那么便会对应子需求建立各自的特性分支(dev_1、dev_2、dev_3)

“冷冻分支” 当这个特性分支上的需求不能上线或者延期上线该怎么处理呢？因为特性分支只存在于一个版本需求开发周期中，这时候，该需求的特性分支便会变为冷冻特性分支，用于代码贮存及项目代码监控。例如dev_pay支付需求出现延期，这个版本上不了了，那么这个时候便会变为freeze_dev_pay,到下个版本上线时，再申请一起上线，这时候冷冻分支便会转化为一个正常的特性分支dev_pay，努力再上线。

HotFix

线上出现bug怎么办？HotFix只包含热修复分支，作为一个最不想看到的分支却存在着很强的必要性，在我们紧急处理线上的问题的时候起到很大的作用。每个热修复分支的生命周期都是极其短暂的，在问题出现的时候，产生于一个master最稳定的tag版本，在问题修复完成后便会合并到master快速上线，上线成功，hotfix也就结束了。热修复分支的名称以hotfix_v_开头，例如一个v1.3的版本出现了线上问题，便会拉一个hotfix_v1.3的分支。

下面是所有的分支管理图

git工作流程管理

版本工作流周期

git-mango是基于需求驱动设计，在整个版本工作流管理中，也是基于需求开发的一个整体流程来划分git-mango的生命周期，分别为需求任务确定阶段、项目开发阶段、测试阶段和版本发布阶段。

git-mango工作流程

1.需求任务确定阶段 圈定上线大需求以及包含的所有子需求，需求确认将会避免具体开发过程中很多的麻烦。需求任务确定好之后，便从master的当前稳定版本分别拉对应的子需求分支，并分配给相应的开发人员。

2.项目开发阶段 在项目开发阶段，对应需求开发人员只在对应子需求分支上进行代码提交,不允许提交到任何其他分支，直到开发结束，由项目负责人对该子需求的完成情况判断是否能够提测。

如果不能提测的话，便继续开发或者直接转化成冷冻分支，下个版本再提测上线，如果基本能够提测的话，由对应开发和测试进行进行冒烟提测。

冒烟测试通过的话，则该需求则进入测试阶段将该dev_特性分支代码合并到sit分支，如果冒烟测试失败的话，则打回继续在原开发分支进行开发。

3.测试阶段 测试阶段发现bug，修复bug在各自的特性分支上进行，不允许在sit上直接修复问题，修复完成后，再合并到sit，提供问题验证，这样能保持特性分支一直保持最新状态并且相对独立，这种做法是为了规避某个需求在测试阶段无法正常上线而影响到其他需求上线。当出现测试阶段有需求实在不能上线的时候，将sit上代码直接回滚到提测前节点，然后把各自能上线的子需求特性分支再次合并到sit分支。

4.版本发布阶段 sit测试通过，则进行代码封版，合并代码到master发布分支上，然后从master分支再打一个待上线包，为上线做最后检验，测试通过则正常上线，并打tag记录当前稳定版本如果测试失败仍有bug的情况下，就需要在sit上进行问题修复，再合并到master，时刻保持sit分支与master分支的同步，无需后期再进行同步，防止漏同步的情况出现。

热修复处理场景 热修复的原则是最快解决问题，最快提交上线。当V1.2线上版本出现线上问题时，立马从master上的V1.2tag拉一个hotfix_v1.2的热修复分支进行问题修复，修复完成在本分支提交测试，测试通过则合并到master分支上，无论是否有其他需求在开发，都强制要求将master同步到sit分支。

git-mango工作流总图

如何在团队中使用git-mango流程

介绍git-mango，团队成员了解后觉得OK再按流程走。
实践中使用，在实践中落地git-mango，有任何问题可以提出优化，在实践中不断地完善流程。
待流程已经形成了习惯并且确实提效时，便可以在团队正式宣布引入git-mango进行git工作流管理。

总结

流程的目标是去流程化，让团队成员潜移默化的养成好的的流程习惯。流程的制定，最重要的是适合团队，提高团队效能。流程的落地，要先投入实践，再迭代优化后再正式投入到使用。