相关概念

开发环境分类

  • 开发环境

    • 最基础的环境
    • 用于日常开发的环境，为了调试方便，会输出全部日志信息。

  • 测试环境

    • 开发环境至生产环境的过渡。

  • 预发布环境

    • 为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。
    • 配置等基本和⽣产环境⼀致，⽬的是能让发正式环境时更有把握。
    • 预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。

  • 生产环境

    • 正式提供对外服务的线上环境。

  • 各类环境的关系如下图所示
    开发环境关系图

GitFlow分支规范

  • GitFlow所涉及的分支总体情况如下表所示：
分支 名称 适用环境 描述
master/main 主干分支 生产环境 与仓库设置 > 分支设置中的默认分支保持一致
develop 开发分支 开发环境 平时开发用的主分支，永远是功能最全最新
feature 需求开发分支 本地 一般一个事项卡对应一个功能分支
release 预发布分支 预发布/测试环境 一般一次新版本的发布对应一个发布分支
hotfix 紧急修复分支 本地 从主干分支拉出，用于线上版本的 Bug 修复

分支介绍

master

  • 主分支，常驻分支、稳定分支、唯⼀分⽀、不可删除
  • GitHub现在叫main分支
  • 只读，不允许直接提交代码，只接受来自release或hoxfix/*分支的merge request
  • 是生产环境中最新代码，存储正式发布的产品，随时处于可部署状态
  • 产品的功能全部实现后，最终在此分⽀对外发布
  • 发布完成后，需要对每个版本进行打标签（tag），⽅便追溯

develop

  • 常驻分支、唯⼀分⽀、不可删除
  • 基于master分支创建
  • 汇总开发者完成的工作成果
  • 始终保持最新完成以及bug修复后的代码
  • 小的改动可以直接在develop分支进行
  • 大的改动要来自feature/*分支或hotfix/*的merge request
  • 可以是缺失功能模块的半成品，但是已有的功能模块不能是半成品

feature

  • 为新功能或新特性开发而创建的临时分⽀，该分支需要关联到具体的JIRA号
  • 以 develop 为基础创建 feature 分支
  • 命名规则：
    • feature/<模块名称>
  • 开发完成后，合并回 develop 分支，并且删除该 feature/* 分支

release

  • 准备发布新版本时使用的分支，⽤于提交给测试⼈员进⾏功能测试
  • 基于 develop 分⽀创建，包含本次上线所有的feature分⽀的merge request
  • 命名规则：
    • release/<版本发布时间>
  • 生命周期从提测开始，bug修复到该版本发布之前为止
  • 测试阶段的bug fix可在该release分支进行操作
  • QA验证完毕，将该版本的release分支merge到master分支和develop分支，并根据版本号为 master 分支添加
    tag，最后删除 release 分支
  • 只能进行质量测试、bug修复、文档生成等面向发布的任务，不能再添加功能不能提交无关代码，如代码优化等

hotfix

  • ⽤于对线上的版本进⾏bug修复
  • 基于 master 分⽀创建
  • 命名规则：
    • hoxfix/<日期>
    • hoxfix/<修复内容>
  • 当问题修复完成后，需要合并到master分支和develop分⽀，为 master 分支添加新的版本号tag，并推送远程
  • 如果此时存在 release 分支，则应该合并到 release 分支
  • 修复上线后，删除此分支

合并方向

  • 合并方向情况可汇总如下表所示：
源分支 目标分支 图示
发布分支 主干分支 release/ -> *master
热修复分支 主干分支 hotfix/ -> *master
功能分支 开发分支 feature/* -> develop
发布分支 开发分支 release/* -> develop
热修复分支 开发分支 hotfix/* -> develop
  • 整体GitFlow流如下图所示：

GitFlow流示意图

提交信息规范

  • 提交信息应该描述做了什么和这么做的原因，必要时还可以加上造成的影响
  • 提交消息的任何一行不能超过100个字符
  • 主要由 3 个部分组成：Header、Body 和 Footer，结构如下：
    1
    2
    3
    4
    5
    <type>(<scope>): <subject>

    <body>

    <footer>
  • type
    • 用于说明提交的类型，共有 9 个候选值：
      • feat：新功能
      • fix：问题修复
      • docs：文档
      • style：不影响代码含义的更改（空白、格式设置、缺失 分号等）
      • refactor：重构，既不修复bug也不添加特性的代码更改
      • test：添加缺少的测试或更正现有测试
      • chore：构建过程或辅助工具的变动
      • perf：改进性能的代码更改
      • revert：撤销以前的提交
  • scope
    • 用于说明提交的影响范围，内容根据具体项目而定
  • subject
    • 用于概括提交内容
  • body
    • 改变的动机，并将其与以前的行为进行对比
    • 若type为revert，则body内容为：This reverts commit <hash>.，其中hash是提交的SHA 正在恢复
  • footer
    • 有关重大变更的任何信息，将PR链接到对应的问题