咱们的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)

标题：项目名-日期

内容分类：

• 新功能
  
• bug修复
  
• 优化
  
• 依赖升级
  
• 重构
  
• 漏洞&补丁
  

示例：

总结

以上做为咱们的团队约定，为的是提供协做规范，提升协做效率。这就像写js代码时，到底要不要在后面加分号同样，并无对错，只是看适不适合你以及你所在的团队。