Git Commit标准和辅助工具

2021-04-04
git
约 1930 字 预计阅读 4 分钟

Git提交规范和管理,代码提交每天可能都会有几十次,有时候为了省事甚至直接重复了上一次的message,这样在后期检查问题以及合并的时候非常麻烦. 社区制定了一些规范和检查工具来统一commit的message

1. commit规范

1.1. 格式

1
2
3
4
5

<type>[optional scope]: <description>
break line
[optional body]
break line
[optional footer(s)]

1.2. type

提交的类型,常用的如下

  • feat: 新的feature
  • fix: 修复issue
  • refactor: 重构
  • docs: 文档相关
  • style: 比如格式化了代码
  • test: 增加或修改了测试
  • chore: 构建过程或者辅助工具的变动

以下是所有可选值

  • build 构建相关代码和文件
  • chore
  • ci
  • docs
  • feat
  • fix
  • perf 优化,性能提升
  • refactor
  • revert 回滚
  • style
  • test

其他可选值

  • merge 合并
  • sync 同步

如果改动比较重要且有破坏性(breaking change)可以在后面加上!, 如果有BREAKING CHANGE:的footer,那必须加上!

1

refactor!: drop support for Node 6

1
2
3

refactor!: drop support for Node 6

BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.

1.3. scope(optional)

这个就是影响范围,比如compile, build, *, view, service, 或者某个业务,某个动作等等,每个项目可以单独制定规范

1.4. description

描述部分, 注意事项

  • 首个单词小写
  • 首个单词是动词
  • 尽量不要超过80字符
  • 不要句号

1.5. Body(optional)

可以多行, 第一行要和header之间有空行, 示例

1
2
3
4
5
6
7

More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

非BREAKING CHANGE的情况下

  • footer和body之间必须有空行
  • footer可以有多行
  • footer必须包含一个关键字
  • footer的关键字如果有whitespace,用-替代, 比如:
  • footer必须是结构化的信息格式, 比如:<space>或者<space>#

示例

1
2

Reviewed-by: Z
Refs #133

单个issue关联

1

Closes #8

多个issue关联

1

Closes #123, #245, #992

一个特殊情况就是BREAKING CHANGE, BREAKING CHANGE不受上面的规范约束

  • 必须大写
  • 后面跟:

示例

1

BREAKING CHANGE: environment variables now take precedence over config files

1.7. 其它注意事项

  • 首字母都是小写
  • 结尾不需要句号
  • 第一行不要超过100字符
  • body部分,每一行不要超过100字符
  • header body footer 之间必须有空行

2. 手动生成ChangeLog

一个ChangeLog应该包含的内容

New features

Bug fixes

Breaking changes.

从git log获取一个版本的所有改动信息

1

git log <last tag> HEAD --pretty=format:%s

获取所有新的features

1

git log <last release> HEAD --grep feat

3. git commit 模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


# Please write your commit messages according to the following specifications 

# <type>[optional scope]: <description>
# break line
# [optional body]
# break line
# [optional footer(s)]

# ======================================
# Type should be one of the following:
# ======================================
#   * build      构建相关代码和文件
#   * chore      构建过程或者辅助工具的变动
#   * ci         CI or CD
#   * docs       文档相关变动
#   * feat       新功能特性
#   * fix        修复
#   * perf       优化,性能提升
#   * refactor   重构
#   * revert     回滚
#   * style      代码样式或者格式化代码
#   * test       测试
#   * merge      合并
#   * sync       同步

# 如果是破坏性的改动,必须加上!,并且在footer加上BREAKING CHANGE:

# ======================================
# Scope:
# ======================================
# scope就是影响范围
# 比如: compile, build, *, view, service
# 根据业务和项目自己把握,能用来区分层次


# ======================================
# Description:
# ======================================
# 字数不要超过80
# 首字母小写
# 第一个是一个动词
# 不要句号

# ======================================
# Description:
# ======================================


# ======================================
# Examples
# ======================================

# feat(*): add library for tailwind
# 
# install development libraries by npm install
#   - postcss
#   - postcss-cli
#   - autoprefixer
#   - @snowpack/plugin-postcss
# 
# Refs #133
# Closes #123, #245, #992

然后将文件放到用户主目录下,之后进行配置全局git提交模板

1

git config --global commit.template ~/.git_commit_template

4. 自动生成ChangeLog

4.1. 辅助工具conventional-changelog

1

npm install -g conventional-changelog-cli

执行命令

1

conventional-changelog -p angular -i CHANGELOG.md -s

如果是第一次想把之前的全部生成出来

1

conventional-changelog -p angular -i CHANGELOG.md -s -r 0

如果是node项目可以在package.json里添加

1

"version": "conventional-changelog -p angular -i CHANGELOG.md -s && git add CHANGELOG.md"

更标准和方便的工具可以使用standard-version

1

npm install -g standard-version

查看帮助

1

❯ standard-version -h

4.2. 正确的使用方式

什么时候需要修改version和changelog

当需要打标签的时候

  • 重大改动
  • 新特性积累更新
  • 修复错误

自动生成

1

standard-version

手动生成(指定版本号)

1
2
3
4

# 直接指定版本号
standard-version -r 1.0.2
# 或者按照major|minor|patch的规则来更新
standard-version -r major

4.3. 推荐的工作流

  1. Make changes
  2. Commit those changes
  3. Make sure Travis turns green
  4. Bump version in package.json
  5. conventionalChangelog
  6. Commit package.json and CHANGELOG.md files
  7. Tag
  8. Push

5. 其它

5.1. 利用commit message自动关闭issue

翻看文档

在commit message里加上相关信息就可以了,gitlab解释的比较清楚,并且可以配置

This translates to the following keywords:

  • Close, Closes, Closed, Closing, close, closes, closed, closing
  • Fix, Fixes, Fixed, Fixing, fix, fixes, fixed, fixing
  • Resolve, Resolves, Resolved, Resolving, resolve, resolves, resolved, resolving
  • Implement, Implements, Implemented, Implementing, implement, implements, implemented, implementing

Note that %{issue_ref} is a complex regular expression defined inside the GitLab source code that can match references to:

  • A local issue (#123).
  • A cross-project issue (group/project#123).
  • A link to an issue (https://gitlab.example.com/group/project/issues/123).

6. references

TAG: git scm
文章作者 : Cocding