Git 提交规范最佳实践

Git 提交规范最佳实践 | 前端进阶之旅

Full translation

完整中文译文

对我们开发者来说，无论是个人项目、多人参与的开源项目，还是由整个社区共同维护的项目，Git 都是必不可少的工具。因此，正确编写 git commit 非常重要。使用连贯且标准化的语言，有助于项目中的所有参与者理解发生了哪些变更。

从上图可以看出，注释不清的 commit 会带来多大的危害：我们无法理解变更的性质，也无法了解变更发生时的上下文。从长期来看，其影响会更加严重。由于这些变更的范围缺乏一致性，也难以追溯它们过去对项目造成的影响，软件的可维护性将受到损害。

基于这一点，下面简单聊聊 Conventional Commits Pattern。

Conventional Commits 是一种简单的 commit message 约定。它遵循一组规则，帮助项目建立明确且结构清晰的 commit 历史记录。

规则非常简单。如下所示，一条 commit message 包含 commit 类型（type）、commit 的上下文（scope）以及 commit 消息（subject）。

!type(?scope): !subject
<?body>
<?footer>

其中，! 表示必填属性，? 表示可选属性。

Subject：使用祈使语气，而不是过去时

通过这种方式，我们是在告诉团队：如果应用这条 commit，它将会做什么。

“如果应用，这条 commit 将……”

“如果应用，这条 commit 将修改标记”，这显然比“如果应用，这条 commit 将已经修改标记”合理得多。

Type：commit 有哪些类型

type 用于说明当前进行的是哪种变更或迭代。按照约定规则，可以使用以下类型：

test：表示创建或修改任何类型的测试代码。例如：创建单元测试。

feat：表示为项目开发新功能。例如：添加服务、功能、endpoint 等。

refactor：用于不影响系统逻辑或规则的代码重构。例如：根据 code review 的结果修改代码。

style：用于不会以任何方式改变系统行为的代码格式和样式变更。例如：修改 style guide、修改 lint 规范、修正缩进、删除空格、删除注释等。

fix：用于修正会在系统中引发 bug 的错误。例如：为行为不符合预期并返回错误的函数添加处理逻辑。

chore：表示不影响系统文件或测试文件的项目变更，通常是开发流程相关的调整。例如：修改 eslint 规则、添加 prettier、向 .gitignore 添加更多文件扩展名。

docs：用于项目文档发生变更时。例如：在 API 文档中添加信息、修改 README 等。

build：用于表示影响项目构建流程或外部依赖的变更。例如：Gulp、添加或删除 npm 依赖等。

perf：表示提升系统性能的变更。例如：将 ForEach 改为 While 等。

ci：用于 CI 配置文件的变更。例如：Circle、Travis、BrowserStack 等。

revert：表示撤销之前的某条 commit。

每条 commit 只能使用一种 type。

type 是必填项。

如果你不知道应该使用哪种 type，那么这次变更可能太大了，可以考虑将这条 commit 拆分成两条或更多 commit。

build 与 chore 之间的区别可能非常细微，容易让人混淆，因此必须注意选择正确的类型。以 Node.js 为例，当添加或修改 devDependencies 中的某个开发依赖时，可以使用 chore。如果添加或修改的是项目的常规依赖，并且会对系统产生直接且实际的影响，则使用 build。

Scope：为 commit 补充上下文

到这里，按照前面的约定，我们已经能够理解这条 commit 所做的变更类型（commit type），也能清楚知道应用它之后会带来什么（commit subject）。

虽然 scope 不是必填项，但可以用它为 commit 补充上下文，并减轻 subject 承载信息的压力，让 subject 尽可能简短精练。需要注意的是，scope 必须放在 commit message 的括号中。

注意：多个 scope 必须使用 / 分隔。

我写这篇文章，是为了记录自己学到的一项知识——它们原本只是 notion app 中的一些笔记。不过，我也希望这些内容能帮助到其他开发者。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。