我们的GIT工作流

概览

dev合并到master触发CI，预发布

下一次迭代功能，也即本次不上线，超前开发的功能，使用feature, 注意使用以下命令合并

git merge --no-ff

线上bug使用hotfix修复，合并回prod及dev分支

详情

基于现在的情况与我们团队习惯，约定可能存在的Git分支如下： 

1. prod 用于生产部署, 需要打tag
   
2. master 用于CI, 旨在提供一个稳定的测试环境，合并prod 
   
3. dev 对本次迭代功能开发 合并到master ，开发人员都有权限 
4. feature 基于dev的下一迭代的功能开发, 一个功能一个分支，合并到dev, 名字格式为: feature-${根据功能取个英文名字} 
5. hotfix 基于prod 修复生产bug ，一次修复迭代(一次上线)一个分支，合并到prod及dev 名字格式为: hotfix-${tag}-${index} tag是要修复的版本的标签号，index是迭代号，从1开始，作为上线顺序
   

下面详细说明工作流： 

1. 假定本周一确定了这周上线功能，开发人员都明确了自己的开发任务 
2. 所有开发人员在dev开发，前端使用mock接口，后端在本地测试接口 
3. 后端人员开发完某完整功能的全部接口后，合并代码到master, 推送触发CI，并通知前端人员可对接真实接口 
4. 相关前端人员调试真实接口，完成后，合并到master，推送触发CI，并通知相关后端人员，相互验证
5. 如果顺利，一切按计划进行，则周五时相关人员把master分支合并到prod, 并打一个tag, 方便回滚，之后便可部署到生产 
6. 特殊情况一：在周三时，有开发人员接到一个新需求，该需求下个迭代上线。由于相关开发人员效率高，此时已经把本周功能开发完了，因此决定超前开发，则相关开发人员基于dev分支checkout一个feature-xxx的分支，不影响本次发布; 在下次迭代时再合并到dev分支, 合并完后删除该分支 
7. 特殊情况二：下周一在dev开发新功能时，发现上周五发布的版本有两个bug，需要紧急修复，权衡之后认为，有一个是当天必须修复的，另一个需要第二天才能上线，则第一个bug的分支为hotfix-${tag}-1, 第二个则为hotfix-${tag}-2。则相关人员基于prod checkout两个分支，进行修改验证后，合并到dev及prod分支， 然后让相关人员打tag,  发布生产，生产验证无误后，删除分支。

解释

以上流程及图片参考了经典文章a-successful-git-branching-model，图片有部分修改。网上大部分谈Git Workflow的文章，思想及内容都源自该文，尤其是其中的图片，一度被人称神。

其实该文有两点内容是与我们最佳实践不符的：

1. dev 进行 nightly build. 之前我们也是如此，但这在接口联调阶段，会造成后端一push代码，就触发CI重新构建，导致接口不可用，所有前端都进入阻塞状态。而后端或测试人员在开发环境验证期间，前端一push代码，导致web应用不可用，所有验证阻塞。这极大的影响了开发/测试体验，甚至到了影响心情的地步，因此取消对dev的CI，只对master进行CI
2. release的命名容易造成误解。在该文中，release其实是预发布分支，做上线前的验证用，但我们成员听上去，误认为是发布分支，专门做上线发布用。为取消分歧，根据现在团队的规模，决定用master作为稳定版，作为上线前的验证分支，而prod则作为真正的上线分支，并在上线前打个tag

标签

tag遵循以下约定

标签名：v版本号(major.minor.patch)

标题：项目名-日期