00-git版本管理策略

一、分支管理

  • master——最为稳定功能最为完整的随时可发布的代码;
  • hotfix——修复线上代码的 bug;
  • develop——永远是功能最新最全的分支;
  • feature——某个功能点正在开发阶段;
  • release——发布定期要上线的功能。

二、分支策略

  1. master分支(需要与版本库同步)
  • 一直是处于可发布状态的代码
  • 合并一次需要打一次标签
  1. develop分支(需要与版本库同步)
  • 最新开发进展的代码
  1. feature分支(临时分支,选择性与版本库同步,看是否是多人协作)
  • 开发一个独立的新功能
  • 起源于develop分支,最终合并回develop分支,或者被丢弃
  • 格式:feature-1786(版本编号)
  • 环境:对应联调环境,或本机
  1. release分支(临时分支,选择性与版本库同步,看是否是多人协作)
  • 版本发布: 短期的发布前准备工作、小bug的修复工作、版本号等元信息的准备工作。与此同时,develop分支又可以承接下一个新功能的开发工作了
  • 产生release最好时机:develop分支已经基本到达预期的状态,至少希望新功能已经完全从Feature合并到develop分支了
    解决打版本到准生产后,准生产bug修复和feature合并到develop分支的冲突
  • 当release处于可发布状态后。 需要完成三个动作:第一是将Release分支合并到master分支,第二是一定要为master上的这个新提交打TAG(记录里程碑),第三是要将Release分支合并回develop分支
  • 格式:release-v1.0.0(产品tag编号)
  • 环境:对应准生产环境,或UAT
  1. hotfix分支(临时分支,选择性与版本库同步,看是否是多人协作)
    bug修复
  • 起源于master分支,最终归并于develop和master
  • 作用: 避免develop分支新功能的开发必须为BUG修复让路的情况
  • 格式:hotfix-1876(版本编号)
  • 环境:对应准生产环境,或UAT

三、场景举例

新功能开发

  1. 更新develop分支

  2. 从develop上创建feature分支。如果是一个人完成的新功能,不需要推送到服务器,如果多人协作,需要推送至服务器

  3. feature分支命名为 feature- 后面的为工程名(自己取)

  4. 在feature分支上完成新功能开发,联调测试

  5. 准备发布,更新UAT、准生产环境,将feature分支合并至develop分支

  6. 更新develop分支,创建release分支

  7. 从release分支部署环境至UAT、准生产环境。如果是一个人完成的新功能,不需要推送到服务器,如果多人协作,需要推送至服务器

  8. UAT、准生产测试完成后,部署生产环境。将release分支合并至develop分支和master分支

  9. 在master分支上打tag

  10. 新功能开发完成

生产bug修复

  1. 更新master分支
  2. 从master分支创建hotfix分支。如果是一个人完成bug修复,不需要推送到服务器,如果多人协作,需要推送至服务器
  3. 在hotfix分支上完成bug修复,联调测试
  4. 从hotfix分支部署环境至UAT、准生产环境
  5. UAT、准生产测试完成后,从hotfix分支部署生产环境
  6. 将hotfix分支合并至develop分支和master分支
  7. 在master分支上打tag
  8. bug修复完成

00-git版本管理策略_第1张图片

你可能感兴趣的:(版本管理,git,github,分支策略,版本管理)