git 工作流

[高性能计算组] git 工作流

标准git流

git flow

分支介绍

• 主要分支
  • dds3/ksc/master: 永远处在稳定状态
  • dds3/ksc/dev: 永远处在测试状态
• 支援分支
  • dds3/ksc/sprint/xx: 迭代开发分支
  • dds3/ksc/sprint/xx/feature_xx: 迭代开发功能分支
  • dds3/ksc/hotfix/xx: 紧急修复分支

角色

• 维护者
• 开发者
• 测试者

git流

---

正常迭代git流

1. 迭代开始，[维护者]从dev分支创建sprint分支
2. 开发开始，[开发者]从dev分支创建feature分支
3. 开发完成，[开发者]发起从feature到sprint的merge request
4. code review，[维护者]进行code review 并将sprint分支合并到dev分支
5. 开始测试，[测试者]在dev代码基础上生成镜像进行测试
6. 测试完成，[测试者]发起从dev到master的merge request，合并merge request之后，在master上打tag

紧急修复git流

1. [开发者]从master分支上创建hotfix分支，进行修复
2. [测试者] 在hotfix代码基础上生成镜像进行测试
3. [测试者] 测试通过后，发起从hotfix到dev和hotfix到master的merge request，合并merge request之后，在master上打tag

---

tips:

1. tag只在master上打
2. 上生产的镜像与测试镜像保持一致
3. 迭代发布镜像从dev上生成，hotfix发布镜像从hotfix上生成
4. 迭代分支进行分支保护，hotfix分支不进行分支保护

操作手册

开发者

1. 修改任何代码的时候先确定在什么分支上修改，如果分支还未建立，则自己建这个分支

2. 开发完成之后，做一次本地merge (sprint -> feature 或 master -> hotfix) ，发起merge request之前必须要做，避免冲突

3. 在gitlab上发起merge request，(feature -> sprint)

4. 通知维护者进行code review

5. merge完成之后通知测试进行测试

测试者

• 在dev或hotfix上build镜像进行测试
• 测试完成后，发起dev -> master或hotfix -> master,hotfix -> dev的merge request，合并merge request
• 在merge完成之后，在master上打tag
• 如果是迭代需求，通知维护者把迭代分支保护