为无线前端团队打造高效git工做流

最新更新：冒烟提测后的一轮、二轮测试阶段，由开发在各自需求分支上打包提供给测试，目前根据项目会生成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构建

为了解决的问题

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

分支管理

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

双主分支

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

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

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

特性分支

特性分支又叫作需求开发分支，做为需求开发使用的分支，在启动新需求开发时都会从master拉出一个最新的需求开发分支，只存在于一个版本需求开发周期中，成功上线即删除分支。特性分支的命名以dev_开头，后面拼接具体的子需求名称，例如dev_pay支付需求的开发分支，若是一个版本上线存在多个子需求，那么便会对应子需求创建各自的特性分支(dev_一、dev_二、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工做流管理。

总结

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