Git commit message规范
文章目录
一.背景
Git 每次提交代码都需要写commit message，否则就不允许提交。一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作。但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见怪，这就导致后续代码维护成本特别大，有时自己都不知道自己的fix bug修改的是什么问题。基于以上这些问题，我们希望通过某种方式能够规范用户的git commit message，让规范更好的服务于质量，提高大家的研发效率。
目前，commit message没有标准的规范，Angular团队的规范是社区比较流行的规范，下面要介绍的也是该规范。
二.Angular团队的规范
它的message格式如下：
<type>(<scope>): <subject>
# 空一行
<body>
# 空一行
<footer>
分别对应Commit message的三个部分：Header，Body，Footer。
2.1 Header
Header部分只有一行，包括三个字符按：type（必须）、scope（可选）和subject（必须）。
-
type：用于说明commit的类型。只允许使用下面的标识：-
feat：增加新功能（feature）。 -
fix/to：修复bug。fix：产生diff并自动修复此问题。适合用于一次提交直接修复bug。to：产生diff不自动修复此问题。适合用于多次提交，最终修复bug提交时使用fix。
-
docs：仅仅是修改了文档，如readme.md。 -
style：仅仅是对格式进行了修改，如逗号、缩进、空格等等，不改变代码的逻辑。 -
build：构造工具或者外部依赖的改动，例如webpack、npm。 -
refactor：代码重构，没有新增功能或者修复bug。 -
revert：版本回退。 -
perf：优化相关，如提升性能、用户体验等等。 -
test：测试拥立，包括单元测试、继承测试等。 -
chore：改变构建流程，或者新增依赖库、工具等。 -
merge：代码合并。 -
sync：同步主线或者分支的bug。
-
-
scope：用于说明commit影响的范围，比如：数据层、控制层、视图层等，视项目不同而不同。 -
subject：用于说明commit目的的简短描述，不超过50个字符，以动词开头，使用第一人称现在时，结尾不加句号或其他标点符号。
综上所述，一个完整的Header如下所示：
fix(view): 修复浏览器不兼容的BUG
2.2 Body
对本次commit修改内容的具体描述，可以分为多行。如下所示：
# More detailed explanatory text, if necessary. Wrap it to
# about 72 characters or so. This should answer:
# - Why was this change necessary?
# - How does it address the problem?
# - Are there any side effects?
注意1：使用第一人称现在时。
注意2：应该说明代码变动的动机，以及与以前行为的对比。
2.3 Footer
Footer是一些备注，通常是不兼容变动或者是关闭Issue。
-
不兼容变动
如果当前代码与上一个版本不兼容，则
Footer部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由的迁移方法。# BREAKING CHANGE: isolate scope bindings definition has changed. # # To migrate the code follow the example below: # # Before: # # scope: { # myAttr: 'attribute', # } # # After: # # scope: { # myAttr: '@', # } # # The removed `inject` wasn't generaly useful for directives so there # should be no code using it. -
关闭
Issue如果当前
commit针对某个issue，那么可以在Footer部分关闭这个issue。# Closes #234也可以一次关闭多个
issue。# Closes #123, #245, #992 -
Revert（可忽视）
还有一种特殊情况，如果当前
commit用于撤销以前的commit，则必须以revert:开头，后面跟着被撤销commit的Header。# revert: feat(pencil): add 'graphiteWidth' option # # This reverts commit 667ecc1654a317a13331b17617d973392f415f02.Body部分的格式是固定的，必须写成This reverts commit <hash>.，其中的hash是被撤销commit的SHA标识符。如果当前
commit与被撤销的commit，在同一个发布（release）里面，那么它们都不会出现在Change log里面。如果两者在不同的发布，那么当前commit，会出现在Change log的Reverts小标题下面.
三.Git 提交信息模板
使用git config配置commit模板，这样可以更加容易的使提交信息遵循格式。
通过以下命令来配置提交信息模板：
git config commit.template [模板文件名] //这个命令只能设置当前分支的提交模板
git config ——global commit.template [模板文件名] //这个命令能设置全局的提交模板，注意global前面是两杠
新建 .gitmessage.txt(模板文件) 内容可以如下:
# header: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# - Why was this change necessary?
# - How does it address the problem?
# - Are there any side effects?
#
# footer:
# - Include a link to the issue.
# - BREAKING CHANGE
四.扩展或插件支持
即使是使用Git配置commit模板信息，在使用起来还是比较麻烦。但是不用担心，我们可以通过扩展来简化该过程。
4.1 git commit template
使用IDEA的话可以下载该插件，此处没有亲自使用过，就不具体介绍了，感兴趣的可以自己尝试。
4.2 git-commit-plugin
使用vscode作为开发工具的话可以下载使用该插件。下面是使用中的一些截图：
按照要求填写好每项内容后，会自动生成commit message，然后点击提交就可以了。
4.3 commitizen
如果是使用终端的话可以使用commitizen。它是一款可以交互式建立提交信息的工具，帮助我们一步步建立提交信息。这里也不详细介绍了，感兴趣的自己去尝试。
五.格式验证
如果是团队开发，对格式要求很严格的话，可以使用commitlint来进行格式验证。
commitlint是一个提交验证工具。原理是可以在实际的git commit提交到远程仓库之前使用git钩子来验证信息。提交不符合规则的信息将会被阻止提交到远程仓库。
六.总结
编码规范、流程规范在软件开发过程中是至关重要的，它可以使我们在开发过程中少走很多弯路。Git commit规范也是如此，确实也是很有必要的，几乎不花费额外精力和时间，但在之后查找问题的效率却很高。作为一名程序员，我们更应注重代码和流程的规范性，永远不要在质量上将就。
5517
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
