代码分支和版本管理规范说明

  • Z时代
  • 2024-01-10
  • 分类：IT

说明：以下是前期公司内部试行的简单的代码分支版本流程管理规范，规范其实和运维有很大的关联，随着管理方式和流程的完善，代码版本管理流程也是会改变的。仅供参考！！！

分支说明

  • dev-xxx 为开发分支，xxx表示版本，建议使用上线年月日时间串，比如dev-20180612 或 为需求功能点名称，比如dev-xx需求

  • test 为测试分支 (如果存在多版本同时测试，可能存在 test-xxx 分支，意思是多个测试环境，有做压测或者是功能测试的)

  • master 主分支为 uat 回归测试分支（预生产/准生产分支）。（此分支会做分支保护，不允许直接 push 和 只有主程序员可以 merge ）

  • prod 为生产发布分支

  • prod-xxx 为生产上线后备份tag

分支版本流程管理

代码分支和版本管理规范说明

图解

  • （1）在主工程仓库，基于 prod 分支创建新开发分支 dev-xxx；

  • （2）开发人员 fork 主仓库到自己名下，（如果原来已经 fork 过，可以通过更新的方式更新获取到最新的master和dev-xxx代码），切换到分支 dev-xxx 进行开发；

  • （3）平时开发正常提交到自己的 fork 仓库，适当时机 PR merge 到 远程项目主仓库对应的 dev-xxx 分支；

  • （4） 如果要提测了，将 dev-xxx 分支代码合并提交到 test 分支；（建议是 fork 仓库的分支 dev-xxx 提交到了远程主仓库的 dev-xxx 分支，再用主仓库的远程dev-xxx分支合并到test 分支）

  • （5）QA 测试过程提 bug，开发人员改 bug 的话，就是重复（3）（4）步骤；

  • （6）QA 验证 test 分支代码通过后，就将 test 分支 PR 合并到 master分支，进行回归测试；

  • （7）如果 uat 测试有 bug，重复（3）（4）（6）步骤；如果 uat 测试失败，运维要回滚 uat 环境和生产一致。

  • （8）uat 测试通过，产品验收通过，则将代码覆盖更新到 prod 分支，进行上线安排，上线出问题还是要有紧急回滚机制。

  • （9）上线验收成功后，给生产 prod 分支版本打标签，如 prod-xxxx（xxx 为上线日期）

(一个完整流程到此结束)

情景举例说明

迭代新版本

当有新需求开发时，一般是经过需求评审后，定下的冲刺迭代版本，评估了开发周期，确认了上线时间。

  • 如果有多个需求（迭代）并行开发，上线时间不一样，那就是不同版本，这时候，需要基于 prod-xxxx 创建一个分支出来，比如取名为 dev-xxxx，然后基于此分支开发同版本的需求上线，要提交 Jenkins 构建的话就 merge 到对应的测试分支。

  • 如果新需求都是同一个版本，步骤同上，只是一个 dev 分支

  • 以上的新需求分支开发完成后，提测的话就 PR 到 test 分支，QA 完成功能测试没问题后，将 test 分支 merge 到 master 分支进行回归测试。

生产上有 bug，需紧急修复上线

  • 基于 prod-xxx 创建分支修改 bug，分支名称为bug-prod-xxx，改完自验没问题需要提交测试的时候，merge 到相应测试分支（如test），Jenkins 构建后验证通过，上线生产。上线完成后，别忘记了备份新生产分支prod-xxxx。然后其他正常使用的分支，需要拉取最新生产分支代码prod-xxxx，保证拥有最新的生产分支代码，避免 bug 又上线了（这个过程在以上把 master 定为准生产分支时规避掉了）。

故事举例：

（一）冲突的新需求情景：

2018-06-09 CRM 前端上线了，上线后开发人员备份了生产分支代码为 prod-20180609，第二天，前端开发人员紧接着开发新需求，并且新需求有两个版本，版本一 是在下周上线；版本二 是在月底上上线。版本一和版本二是不同的开发人员，启动开发时间是一样的。这时候，开发人员应该基于 master 分支创建出两个分支，假设为 dev-20180618-需求1 和 dev-20180625-需求2，然后他们都是各自在各自分支里边开发，相互不影响。

  • 提交测试前的任何分支，都要拉取一下主分支master，合并最新生产代码（因为可能会有遗漏，有人改过没更新同步你们的分支），然后再 PR 到 test 分支测试。

（二）线上 BUG 情景：

问题来了：上线后第三天，线上用户反馈了 bug，需要紧急修复。

做法：基于远程仓库主分支的版本标签 prod-20180609 创建新分支bug-prod-xxx，在此新分支修改 bug，自测没问题后 PR 到主仓库 test（如果该分支已经被新需求占用，可以创建新分支test-bug，Jenkins 构建选对就好），jenkins构建后 QA 测试，没问题后，将 test 分支 merge到 master 分支，没问题后再覆盖更新到 prod上线,上线完成后，备份新生产分支，打标签prod-xxxx。

（三）公共代码（非需求代码变动）情景：

修改公共代码的同学，需要自己创建一个专门用来改公共代码的分支出来。公共代码或者是公共类库和基础服务等代码改动了，也要和业务代码一样，提测走完测试流程。

以上是 代码分支和版本管理规范说明 的全部内容， 来源链接： utcz.com/p/232855.html

回到顶部