create by db on 2021-1-25 16:34:46
Recently revised in 2021-1-25 19:34:56闲时要有吃紧的心思，忙时要有悠闲的趣味
前言
无规矩不成方圆，编程也一样。
如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。
这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。
Git Commit 规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的提交信息（更可怕的是没有提交信息），恐怕会懊恼不已吧。
正文
提交规范的作用
很多时候，看提交历史的人跟提交代码的人都不是同一个人，当别人阅读你的提交历史时，他很可能是不知道具体代码细节的，你如何在最短的时间内让他一眼知道每次提交的意义：
- 每次提交影响的具体范围？
- 这个 bug 在哪次提交中被修复了？
- 这个新功能是在哪次提交中增加的？
- 修改是否向下兼容？
- 是否回滚了代码？
- 是否只是修改了文档、调整了代码格式？
- 是否修改了测试、是否进行了重构？
- 是否对代码进行了性能优化？
提交规范的格式
用什么规范？
现在比较流行的方案是约定式提交规范（Conventional Commits），它受到了 Angular 提交准则的启发，并在很大程度上以其为依据。
约定式提交规范 是一种基于提交消息的轻量级约定。 它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与 SemVer（ 语义化版本（Semantic Versioning）规范 的一个实现，目前是由 npm 的团队维护，实现了版本和版本范围的解析、计算、比较。） 相吻合，在提交信息中描述新特性、bug 修复和破坏性变更。
每个提交消息都由一个header(标题)、一个body(正文)和一个或多个footer(s)(页脚)组成。
它的 message 格式如下:
< type > [optional scope]: < description > // header
// 空一行
[optional < body > ]
// 空一行
[optional < footer(s) > ]
举个简单的例子：
feat(config): 允许 config 对象直接从其他 config 继承
BREAKING CHANGE: 在 config 对象中增加 `extends` 字段，用于从其他继承 config
close issue #23
当然我们也可以写的简洁一些
feat: 允许 config 对象直接从其他 config 继承
注：
- 在命令行里 git commit 时，如果你想进行多行 commit 编辑，可以通过
git commit -a进入编辑界面；如果是单行，可以直接git commit -m 'COMMIT MESSAGE'完成提交。
格式讲解
一. header(标题 必填)
header 部分只有一行，包括三个字段： type （必需）、 scope （可选）和 description （必需）。
其中最重要的就是 header 这部分，至于 <body> 和 <footer(s)> 可省略
例如:
feat:新增表格组件
1. type(修改类型 必填)
type 为必填项，用于指定 commit 的类型，约定了 feat 、 fix 两个主要 type，以及 docs 、 style 、 build 、 refactor 、 revert 五个特殊 type，其余 type 暂不使用。（参考人人贷大前端技术中心）
# 主要type
feat: 增加新功能
fix: 修复bug
# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert: 执行git revert打印的message
# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
注：
- 当一次改动包括主要 type 与特殊 type 时，统一采用主要 type。
2. scope(影响范围 选填)
可选项，用来说明此次修改的影响范围，格式为项目名/模块名，可以是一个文件的地址，如 /lib/utils ；也可以是某个功能点 parser，不建议超过两个单词
如：
.all //表示影响面大 ，如修改了网络框架 会对真个程序产生影响
.loation //表示影响小，某个小小的功能
.module //表示会影响某个模块 如登录模块、首页模块 、用户管理模块等等
注：
- 如果一次 commit 修改多个模块，建议拆分成多次 commit，以便更好追踪和维护。
3. description(描述 必填)
必填项，是 commit 目的的简短描述，不超过 50 个字符。
规范如下：
- 以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes
- 第一个字母小写
- 结尾不加句号（.）
二. body(正文 选填)
body是对标题的补充，但它不是必须的。
body 主要描述改动之前的情况及修改动机，对于小的修改不作要求，一般不用写。但是重大需求、更新等必须添加 body 来作说明。
三. footer(s)(页脚 选填)
可选项，放置备注啥的，一般不用写。它经常用来引用本次提交解决的GitHub Issue。 如果是 bug ，可以把 bug ID放。
相关工具推荐
Vscode插件（Git-commit-plugin For Vscode）
这个一个VSCODE插件的,对于喜欢使用Vscode编码的朋友来说用起来很方便的。
使用详情请参考 Git-commit-plugin For Vscode 一款自动生成规范git提交信息的插件 | segmentfault - redjue
commitizen
这个一款基于 Node 的交互式约束命令工具，适合喜欢使用命令行的小伙伴。
使用详情请参考 Git commit message 规范 | 掘金 - 人人贷大前端技术中心
git 设置模板
对于喜欢使用 如sourceTree一样有着界面的git工具的同学，就可以采用 git 配置模板的方式。
使用详情请参考 老鸟都应该注意的git 提交规范| 博客园 - Four two
总结
实际中工作中，我们不一定要采用这种规则，但是可以借鉴它，然后自己那边再根据实际情况变动。毕竟，适合的才是最好的。
另外关于什么时候提交，尽可能是完成一个新的功能或者是优化某个功能，解决某个 bug 等就提交（commit），避免一次提交很多更改，那样不好回溯。
人生苦短，遵守规范。
路漫漫其修远兮，与诸君共勉。
参考文档：
后记：Hello 小伙伴们，如果觉得本文还不错，记得点个赞或者给个 star，你们的赞和 star 是我编写更多更丰富文章的动力！GitHub 地址
文档协议
db 的文档库 由 db 采用 知识共享 署名-非商业性使用-相同方式共享 4.0 国际 许可协议进行许可。
基于github.com/danygitgit上的作品创作。
本许可协议授权之外的使用权限可以从 creativecommons.org/licenses/by… 处获得。
