一、背景

团队开发中，遵循一个合理、清晰的 Git 使用流程，是非常重要的。 否则，各种不清晰的分支，再加上一堆杂乱无章的commit，在后续的查找定位问题和产品迭代维护会让你知道什么是头疼的。

如果项目中只有两三个人开发，其实也不需要严格的规范，只要把提交内容写清楚就行，但是大型项目，开发人员较多，规范提交还是有必要的

所以，我们会从以下几个方面来讲:

  • 分支命名规范
  • 分支使用规范(git-flow)
  • commit 规范

二、分支命名规范

(1) master 分支

  • master 为主分支，用于部署生产环境，要确保稳定性
  • master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改 master 分支代码
  • 每次更新master，都需对master添加指定格式的tag(git tag -a v0.0.1 -m “填写描述”)，用于发布或回滚

(2) develop 分支

  • develop 为开发分支，始终保持最新完成以及bug修复后的代码
  • 一般开发新功能时，feature 分支都是基于 develop 分支下创建的

(3) feature 分支

  • 开发新功能时，以 develop 分支为基础创建 feature 分支
  • 分支命名: feature/ 开头的为特性分支， 命名规则: feature/module_userName_date

例子： feature/lowCodeConfigs_yaoLing_20201015

(4) release 分支

  • release 为预发布分支，发布提测阶段，以 release 分支代码为基准提测

(5) hotfix 分支

  • 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
  • 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支

三、分支使用规范(git-flow)

git-flow

新功能开发流程

  1. 从 develop 分支创建 feature 分支
  2. 开发调试完将 feature 分支提交到远程版本库
  3. 提交 pull request 请求 Merge 到 develop 分支
  4. 相关负责人 code review
  • 同意合并后，删除远程 feature 分支
  • 不同意，重新修改后上传 feature 分支，回到第3步执行
  1. 依赖develop分支构建测试环境，质量工程师功能测试验收
  • 测试问题直接在develop分支修复
  1. 测试环境验收通过，且合并develop分支至release分支，release分支填入最近"日常发布日"发布计划，发布预发环境，邀请产品和视觉团队验收
  • 预发问题在测试分支修复，修复完成后返回第5步
  1. 预发环境验收通过，发布日自动构建部署，正常发布。邀请产品团队生产验收，确认无误则合并release分支到master分支和develop分支

紧急问题修复流程

  1. 从 master 分支创建 hotfix 分支且申请填写“紧急发布计划”
  2. 修复完将 hotfix 分支提交到远程版本库
  3. 提交 pull request 请求 Merge 到 release 分支
  4. 相关负责人 code review
  • 同意合并后，删除远程 hotfix 分支
  • 不同意，重新修改后上传 hotfix 分支，回到第3步执行
  1. 依赖 release 分支构预发环境，质量工程师功能测试验收
  • 问题直接在 release 分支修复
  1. 预发环境验收通过，启动紧急发布计划自动构建部署，正常发布。邀请产品团队生产验收，确认无误则合并release分支到master分支和develop分支

注意：实际项目中，由于需求的复杂性，可能同时存在多个测试分支、预发分支

四、commit 规范

下面代码的 -m 参数，就是用来指定 commit message 的

$ git commit -m "commit message"

一般来说，commit message 应该清晰明了，说明本次提交的目的。而且多人协作的时候，有问题也方便查看提交日志。

如果一行不够，可以只执行git commit，就会跳出文本编辑器，让你写多行

目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化

参考 angular/angular.js commits 记录。

Commit message 包括三个部分：Header、Body 和 Footer

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 可以省略。为了避免自动换行影响美观，每部分，任何一行都不要有太多字符

1、Head

Header部分只有一行，包括三个字段：type（必填）、scope（影响范围，选填）和subject（必填）

type，必选
commit 的类别，只允许使用以下标识（或用对应的 emoji 表情，在前边再加一个: 就会显示了）

  • feat：新增功能（✨）
  • fix：修补bug（ 🚑）
  • docs：修改文档（📚）
  • style： 格式化代码结构，无逻辑上的代码修改（🎨)
  • refactor：重构，即不是新增功能，也不是修改bug的代码变动，比如重命名变量（🚜）
  • test：增加测试代码，单元测试一类的，没有生产代码的变更（🔬）
  • chore：构建过程或辅助工具的变动（不会影响代码运行）
  • revert：回滚到上一个版本。
  • merge：代码合并。
  • sync：同步主线或分支的Bug

特殊情况，当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header

revert: feat: 设计器 Configs 基础配置
This reverts commit 660ecc1654a317a13331b17617d973392f418f02

推荐一个编写 Commit message 的工具 Commitizen

scope: 可选。用于定义 type 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同

subject: 必选。commit目的的简短描述，不超过50个字符

2、Body
Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符

3、Footer
Footer 部分只用于两种情况:

  • 不兼容变动: 如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法
  • 关闭 Issue：如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue
Closes #234
Closes #123, #245, #992

示例

  • feat: 设计器 Configs 基础配置
  • fix: 修复Container Page特殊属性联动切换问题
  • style: delete 冗余联调阶段debugger
  • docs: 更新api文档
  • chore: 升级 monaco-editor 及对应babel 插件包版本
  • refactor: 重构Configs 方案（预设->动态拓展）

参考

最后， 希望大家早日实现：成为编程高手的伟大梦想！
欢迎交流~

微信公众号