Git如何规范填写Commit Message

0.规范commit message的好处

• 可以清晰地知道每个 commit 的变更内容
• 可以基于这些 Commit Message 进行过滤查找，比如只查找某个版本新增的功能：git log --oneline --grep “^feat | ^fix| ^perf"
• 可以基于规范化的 Commit Message 生成 Change Log。
• 可以依据某些类型的 Commit Message 触发构建或者发布流程，比如当 type 类型为 feat、fix 时我们才触发 CI 流程。
• 确定语义化版本的版本号

1.commit规范

目前使用最多的是Angular 规范，在功能上能够满足开发者 commit 需求，在格式上清晰易读。
Commit Message 包含三个部分，分别是 Header、Body 和 Footer，格式如下：

<type>[optional scope]: <description>
// 空行
[optional body]
// 空行
[optional footer(s)]
1
2
3
4
5

[optional scope]后必须紧跟冒号 ，冒号后必须紧跟空格

看一下Angular开发者们的提交

1.1 Header

Header 部分只有一行，包括三个字段：type（必选）、scope（可选）和 subject（必选）。

为了方便记忆，我们可以把type归为：

• Development：这类修改一般是项目管理类的变更，不会影响最终用户和生产环境的代码，比如 CI 流程、构建方式等的修改。遇到这类修改，通常也意味着可以免测发布。
• Production：这类修改会影响最终的用户和生产环境的代码。所以对于这种改动，我们一定要慎重，并在提交前做好充分的测试。

type没有必须这样选择，在项目中只要保证大家使用的的type一致就好了

---

scope（可选）：scope 是用来说明 commit 的影响范围的，在项目初期，我们可以设置一些粒度比较大的 scope，比如可以按组件名或者功能来设置 scope；后续，如果项目有变动或者有新功能，我们可以再用追加的方式添加新的 scope。当然只要团队成员定一个标准即可

---

subject： 是 commit 的简短描述，必须以动词开头、使用现在时。比如，我们可以用 change，却不能用 changed 或 changes，而且这个动词的第一个字母必须是小写。通过这个动词，我们可以明确地知道 commit 所执行的操作。此外我们还要注意，subject 的结尾不能加英文句号。

1.2 Body（可选）

Header 对 commit 做了高度概括，可以方便我们查看 Commit Message。而Body测试对本次提交的详细描述，格式比较自由，可选，要包括修改的动机，以及和跟上一版本相比的改动点。

1.3 Footer（可选）

可以根据需要来选择，主要用来说明本次 commit 导致的后果。在实际应用中，Footer 通常用来说明不兼容的改动和关闭的 Issue 列表

2.提交频率

• 只要我对项目进行了修改，一通过测试就立即 commit。比如修复完一个 bug、开发完一个小功能，或者开发完一个完整的功能，测试通过后就提交。
• 我们规定一个时间，定期提交。这里我建议代码下班前固定提交一次，并且要确保本地未提交的代码，延期不超过 1 天。这样，如果本地代码丢失，可以尽可能减少丢失的代码量。

3.合并提交

git rebase -i 进入一个vim编辑界面

这个交互界面会首先列出给定之前（不包括，越下面越新）的所有 commit，每个 commit 前面有一个操作命令，默认是 pick。我们可以选择不同的 commit，并修改 commit 前面的命令，来对该 commit 执行不同的变更操作
git rebase 支持的变更操作如下:

留一个pick，其他的改为squash，然后：wq保存即可

合并完成：

当然还有一个种方式就是，先进行版本回退然后在重新提交，也可以达到commit合并的效果

4.IDEA中commit message插件

在idea中下载Git Commit Template插件

当提交代码时选择：

可以直接在界面中操作提高效率