GitFlow流程梳理

怒放的生命大大
1,683 阅读8分钟

一、介绍

  1. Git 作为源码管理系统，不可避免涉及多人协作；
  2. 协作必须有一个规范的工作流程，让大家有效合作，使得项目井井有条发展下去；
  3. 本文给大家介绍一种采用最多的工作流程，Git flow;
  4. 'flow'原意是水流，比喻项目像水流那样，顺畅、自然向前流动，不会发生冲击、对撞、甚至旋涡；

flow

二、当前问题

  1. 流程太复杂，merge操作太多，对开发人员不友好；
  2. 修复bug提交代码链路过长，太麻烦，开发同学不清晰在哪个分支修改代码，合并到哪个分支，感觉很乱；
  3. 人工操作越多，出错率越高，都是潜在风险；
  4. 新人不清楚团队代码提交规范，因此有必要输出文档；

聊天截图

三、目标

  1. 提高研发效率和代码质量
  2. 降低生产事故
  3. 成功的git分支模型

git branch model

四、适用情况

  1. 固定的迭代周期，比如2~3周一个版本
  2. 按照版本节奏开发，每个迭代结束后进行一次产品发布。迭代周期中不发布产品，除非是紧急问题（hotfix）

五、特点

1. 项目存在两个长期分支

主分支（master/prod）
开发分支（develop/dev）

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的版本；后者用于日常开发，存放最新的开发版。

2. 项目存在三种短期分支

功能分支（feature）
预发布分支（release/test）
补丁分支（fixbug）

一旦完成开发，它们都要合并进develop或者master，然后被删除

六、常用分支

  • 生产分支（master/prod） Master分支是仓库的主分支，提供给用户使用的正式版本，这个分支包含最近发布到生产环境的代码，最近发布的Release(test)， 这个分支只能从其他分支合并，不能在这个分支直接修改‌

  • 开发分支（develop/dev）

    • 这个分支是我们的主开发分支，包含所有要发布到下一个Release(test)的代码，这个主要从其他分支合并过来的，比如Feature分支‌，Release（test）分支、fixbug分支
    • Git创建Develop分支的命令：
    git checkout -b develop master

  • 功能分支（feature）

    • feature分支主要是用来开发一个新的功能，从Develop分支上面分出来的，开发完成后，要再并入Develop;

    • 功能分支的名字，可以采用feature-*的形式命名，如（feature-v2.1.0）

    • 创建一个功能分支：

        git checkout -b feature-v2.1.0 develop
    • 开发完成后将功能分支合并到develop分支：
        git checkout develop
    git merge --no-ff feature-v2.1.0
    • 删除feature分支：
        git branch -d feature-v2.1.0

    • 这里解释下 --no-ff 参数什么意思

      • 使用--no-ff参数后，会执行正常合并，在develop分支上生成一个新节点。
      • 默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将develop分支指向feature分支。

      --no--ff

  • 预发布分支（release/test）

    • 该分支是发布正式版本之前（即合并到Master分支之前），需要一个预发布的版本进行测试，预发布分支是从develop分支分出来的，测试验证OK之后，必须合并进develop和master分支。
    • 创建一个预发布分支
        git checkout -b test develop
    • 测试验证没问题之后，合并到master分支
        git checkout master
    git merge --no-ff test
    • 再合并到develop分支
        git checkout develop
    git merge --no-ff test
    • 最后，上线没问题后，删除预发布分支
        git branch -d test

  • 修补线上bug分支

    • 程序正式发布以后，难免会出现bug，线上事故需要引起足够重视，这时需要创建一个分支，紧急修复
    • 修复bug分支是从master分支分出来的，修补结束以后，再合进master和develop分支，命名采用fixbug-*的形式（fixbug-20210724）
    • 创建一个修复bug分支
        git checkout -b fixbug-20210724 master
    • 修补结束以后，合并到master分支
        git checkout master
    git merge --no-ff fixbug-20210724
    • 然后再合并到develop分支
        git checkout develop
    git merge --no-ff fixbug-20210724
    • 最后，删除修补bug分支
        git branch -d fixbug-20210724

七、角色（role）

良好的管理规范能适当减少生产事故，提高研发效率，研发部门的人员大概可分为：

  • 开发组长

  • 开发同学

  • 测试同学

  • 运维同学

    • 开发同学需要做的操作

      1. 需求启动的时候，切换到对应的feature分支开发需求，完成编码，前后端联调时，本地代理后台dev环境接口联调，自测通过后，提交代码；
      2. 如果体验开发环境的效果，提交merge request，提前合并代码到develop，否则就等着其他人代码都提交到feature分支，由组长一起merge到develop分支；
      3. 修复bug，直接在test分支修复bug，提交代码，自己可以不用构建，让测试同学自己构建，或者集中某个时间点统一构建，避免频繁构建； 总结： 提测前在feature分支开发新需求，提测后在test分支修复bug。

    • 开发组长需要做的操作

      1. 编码、创建新的功能分支、处理merge request、code Review；
      2. 将feature分支合并到develop，创建test分支；
      3. 测试验证ok后，进行灰度验证；
      4. 灰度没问题后，正式发布上线，将test合并到develop和master，master分支打tag
      5. 如果发布后线上问题较多，比如几十个bug，test分支暂时不删除，继续在test分支改bug，继续验证；
      6. 线上稳定后删除test分支；
      7. 线上如果再出现问题，创建fixbug分支，安排对应的人紧急修复，处理完后合并分支到develop和master分支；

    • 提交代码发生冲突时

      1. 知道冲突的原因，自己能解决最好；
      2. 不确定的时候不要随意覆盖，找与冲突代码的开发，协同解决；
      3. 与冲突的人都不知道怎么解决，找组长协助处理；
      4. 以上还不能解决，抛出问题，大家一起解决；

八、代码提交规范

每次提交，Commit message 格式包含三个字段： type（必需）、scope（可选）和subject（必需）

<type>(<scope>): <subject>

// 例子：fix(comfirmOrder): 修复虚拟订单入参错误问题

1. type type用于说明 commit 的类别，只允许使用下面7个标识。

  • feat：新功能（feature）
  • fix：修复bug
  • docs：文档（documentation）
  • style：格式
  • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  • test：增加测试
  • chore：构建过程或辅助工具的变动

2. scope scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

3.subject subject是 commit 目的的简短描述，不超过50个字符。

九、git stash 用法

应用场景

  1. 当正在feature分支开发某个需求，这时项目中出现一个bug需要你紧急修复，但是开发内容只完成一半不想提交，此时可以用git stash命令将修改的内容保存至堆栈区，然后切到fixbug分支进行bug修复，修复完成后再次切回feature分支，用git stash pop从堆栈中恢复刚刚保存的内容
  2. 由于疏忽，本应该在feature分支开发的内容，却在master上进行了开发了，需要重新切回到feature分支上进行开发，可以用git stash将内容保存至堆栈中，切回到feature分支后，再次恢复内容即可

常用命令详解

1. git stash // 能够将所有未提交的修改（工作区和暂存区）保存至堆栈中，用于后续恢复当前工作目录。

2. git stash save // 作用等同于git stash，区别是可以加一些注释
    例如: git stash save "test1"

3. git stash list // 查看当前stash中的内容

4. git stash pop // 将当前stash中的内容弹出，并应用到当前分支对应的工作目录上。
    注：该命令将堆栈中最近保存的内容删除（栈是先进后出）

5. git stash clear // 清除堆栈中的所有的内容

十、其他

  1. 开发的分支，联调过程中开发人员自己构建
  2. 测试的分支（test），开发只需要修复bug，提交代码，部署让测试同学自己部署，避免测试过程中被频繁中断，都是jenkins一键部署（除非测试主动要求开发帮其部署）
  3. 小程序分支规范同理，提测之前在feture分支开发，提测之后在test分支修复bug，小程序发布体验版用test分支
  4. 未完待续...

十一、总结

整理了一张研发阶段的时间线，主要有三个关键时间节点，分别是启动开发、提测、上线，简单介绍了在各个阶段，开发同学需要做的事情。 develop process

备注：

  • 文中如有错误，欢迎指出
  • 本篇文章抛砖引玉，有好的想法，欢迎分享

参考资料

avatar
文章
阅读
粉丝