阅读 2913

我们的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代码时,到底要不要在后面加分号一样,并没有对错,只是看适不适合你以及你所在的团队。











文章分类
前端