背景
在软件开发流程中，git或者其他的版本控制工具已经成为必不可少的一部分。Git每次提交代码都需要写commit message，否则不允许提交，一般来说commit message应该清晰明了,说明本次提交的目的，这对于之后bug定位，问题的分析都有很大的帮助。但是在日常开发中，大家的commit message都千奇百怪，fix issue，fix bug等等笼统不清晰的git message充斥在git history中，这就导致后续维护人员无法快速定位问题，有时甚至自己提交的代码都不知道是为什么，所以我们就需要一个规范来统一和管理commit message。
规范梳理
目前比较知名的规范是Angular的commit message规范 ,同时也有很多相对应的IDE插件，比如Intellij IDEA的Git Commit Template 来帮助实现规范。现在以Angular的规范为基础介绍一套较为通用的git commit message规范。
Commit Message Format
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
每一个commit message都应该包含header，body和footer。其中footer可以省略，但是header和body都不能为空。
Header
Header分为三个部分type, scope, summary，其中type和summary为必填项，scope可以省略，格式如下:
<type>(<scope>): <summary>
-
Type:
用于说明git commit的类别，只允许使用下面的标识。
feat: 新功能（feature）。
fix: 修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
docs: 文档（documentation）。
style: 格式（不影响代码运行的变动）。
refactor: 重构（即不是新增功能，也不是修改bug的代码变动）。
perf: 优化相关，比如提升性能、体验。
test: 增加测试。
chore: 构建过程或辅助工具的变动。
revert: 回滚到上一个版本。
-
Scope
Scope用于说明 commit 影响的范围，比如Controller、DAO、View等等，视项目不同而不同。例如在Angular中可以是:
- animations
- bazel
- benchpress
- common
- compiler
- compiler-cli
- core
- elements
等等，如果其中包含了多个scope，可以用逗'*'隔'。
-
Summary
Summary是对commit的一个简短的描述，一般Git Commit Head总共不超过50个字符，所以summary必须精简。对于英文的commit summary，第一，要使用第一人称，现在时，比如change，不是changed也不是changes，第二，首字母无需大写，第三，句尾不要标点符号。中文除了时态，其他也一样。
根据上述规范git commit message header可以如下:
fix(Controller): request url map typo
Body
和Header中的summary一样。同时需要解释提交的动机，为什么需要更改，可以和之前的行为进行比较，来说明改动的影响等等。
Footer
Footer适用于当提交的改动包含了不可兼容变化或者弃用的变化，Footer部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法，同时可以把相关Github issue，JIRA ticket或者其他文档链接填入其中。例子如下:
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>
DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>
Revert
还有一种特殊情况，如果当前commit用于撤销以前的commit，则必须以revert:开头，后面跟着被撤销commit的Header。
revert: fix(Controller): request url map typo
This reverts commit {commit hash id}
Commit message的使用
-
提供更多的Git History信息
当浏览Github Commit History页面时，只要看首行就可以知道某次的commit的目的，如果没有GUI工具，使用命令行工具使用
git log <last tag> HEAD --pretty=format:%s也能很方便清晰的浏览每次改动的信息。 -
快速查找Commit信息
用命令行工具，可以很方便的查找出，或者过滤出相关的commit
git log <last release> HEAD --grep perf例如上面的命令，就可以迅速的查处所有perf，性能修改相关的commit。
总结
编码规范、流程规范在软件开发过程中是至关重要的，它可以使我们在开发过程中少走很多弯路。之所以写这篇文章，是因为笔者每次在填写commit message的时候都很纠结，明明知道随意写不好，但是又不知道什么样的commit message才是规范合适的。制定一个Git Commit规范，在提交时就会几乎不花费额外精力和时间，但在之后查找问题的效率却很高。同时可以结合IDE的Git Commit插件或者添加Git Hook来强制规范的执行。
