美文网首页
git 工作流

git 工作流

作者: 十一品莲台 | 来源:发表于2017-09-21 14:10 被阅读0次

    [高性能计算组] 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
    • 如果是迭代需求,通知维护者把迭代分支保护

    相关文章

      网友评论

          本文标题:git 工作流

          本文链接:https://www.haomeiwen.com/subject/zbizsxtx.html