THE ONE
WikiAboutLinks
GIT 提交规范 & 自动化版本管理

GIT 提交规范 & 自动化版本管理

Tags
FED
开发
Description
Published
May 17, 2021

Why？

  • 自动化生成 CHANGELOG
  • 基于提交类型，自动化的语义化版本变更
  • 记录详细的变更记录、结构化的提交历史，而不是无意义的 commit 信息
  • 自动化触发构建及部署流程

Git 提交规范

目前主流的 Git 提交规范有以下两种：
Conventional Commits （约定式提交规范） 是目前使用最广泛的提交信息规范，个人也比较推崇改规范。

规范化信息结构

<type>[optional scope]: <subject>
// 空一行
[optional body]
// 空一行
[optional footer(s)]

规范化信息结构说明

type 必选，表示提交类别，必须为以下几种类型之一
fix：bug 修复
feat：feature 增加新功能
docs：只修改了文档
style：做了不影响代码含义的修改，空格、格式化、缺少分号等等
refactor：代码重构，既不是修复bug，也不是新功能的修改
perf：改进性能的代码
test：增加测试或更新已有的测试用例
chore：构建或辅助工具或依赖库的更新
...
scope 可选，表示影响的范围、功能、模块
subject 必填，代码提交的简单说明，不超过50个字
body 选填，用于填写更详细的描述
footer 选填，用于填关联 issus 或者 BREAK CHANGE
其中 BREAKING CHANGE 必须是大写，**表示引入了破坏性 API 变更，通常是一个大版本的改动。**BREAKING CHANGE 之后必须提供描述
示例如下（包含BREAKING CHANGE）：
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

规范化约束

规范化约束的问题必须借助工具和脚本校验，依靠人为的校验始终是不可靠的。
规范化提交 可借助 commitizen 帮我们生成符合规范的 git commit 信息
如何使用和配置 commitizen：
1、安装 commitizen 及 cz-conventional-changelog
# 全局安装
yarn global add commitizen
# 或者本地安装（推荐本地安装）
yarn add commitizen -D
# 安装适配器
yarn add cz-conventional-changelog -D
2、指定使用哪种 commit 规范
在项目的 package.json 中新增如下字段：
"config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }
3、使用 git cz 代替 git commit
接下来你将看到下图所展示的信息，然后按照提示一步一步填写相关信息即可完成规范化的提交
notion image
格式校验 commitlint 前面我们已经配置了 commitizen 来协助我们规范化 git 提交，但其实并不能覆盖到非交互式提交的场景（例如
git commit -m 'message'
），此时为了保证提交信息的准确性，我们需要借助
husky
对 commit 信息进行格式化校验。
1、安装 commitlint 及 husky
# 安装 commitlint
yarn add @commitlint/cli -D
yarn add @commitlint/config-conventional -D
# 安装 husky
yarn add husky -D
2、新增 commitlint.config.js 到项目根目录
// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional']
};
3、新增 husky hook
// 在 package.json 中新增以下配置
"husky": {
		"hooks": {
			"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
		}
	}

自动版本管理和生成 CHANGELOG

规范化的提交信息除了能很好描述项目的修改情况，还可以根据提交记录来生成对应的 CHANGELOG 和自动化版本管理等功能。

自动化版本管理（standard-version）

一个用于生成 CHANGELOG.md 和进行 SemVer(语义化版本号) 发版的命令行工具
主要功能：
  • 自动修改最新版本号，可以是 package.json 或自定义文件
  • 读取最新版本号，创建一个最新的 git tag
  • 根据提交信息，生成 CHANGELOG.md
  • 创建一个新提交包括 CHANGELOG.md 和 package.json 的变更

语义化版本控制（SemVer）

具体语义化版本控制相关知识此处不在赘述，详情请查看 -> 语义化版本 2.0.0 知识扫盲
了解以上两个知识点之后，我们需要借助 standard-version 帮我们完成对应版本号的修改，需要注意一下几点：
standard-version 会根据提交的信息类型来自动更改对应的版本号,如下:
  • feat: 次版本(minor)+1
  • fix: 修订号(patch) +1
  • BREAK CHANGE: 主板号(marjor) +1
standard-verstion 生成的 CHANGELOG 只会包含feat、fix、BREACK-CHANGE 类型的提交记录
 
  • 如何使用：
1、安装
yarn add standard-version -D
2、新增 npm script
{
 scripts:{
   "release": "standard-version",
   "release:alpha": "standard-version --prerelease alpha",
   "release:rc": "standard-version --prerelease rc"
  }
}
3、执行 script
yarn run release

#指定类型 patch/minor/marjor
yarn run release -- --release-as patch
#指定版本号
yarn run release -- -- release-as 6.6.6

Git 工作流

推荐使用 git-flow 工作流，但并非强制使用该工作流，该分支管理规范的分支管理思想值得借鉴
git-flow 的工作流程扫盲
项目中常用一些分支如下：
  • master - 主分支
  • develop - 长期开发分支（长期开发分支发布后需合并到 master 分支及 release 分支归档）
  • feature - 短期功能分支
  • release - 版本存档（存储每一个版本的发布归档）
  • refactor - 重构分支
  • hotfix - hotfix 分支

参考