Git 提交模式

对我们开发者来说，使用 Git 至关重要，无论是个人项目、多人参与的开源项目，还是整个社区。因此，正确使用git commit
至关重要 。使用一种连贯且标准化的语言，有助于项目中的每个人理解发生的变更。

从上图可以看出，注释不充分的提交会带来多么严重的危害，因为我们无法理解所发生变更的性质及其背景。长远来看，其影响甚至更加严重，因为这些变更范围的不一致以及它们过去对项目的影响，会损害软件的可维护性。

考虑到这一点，让我们稍微讨论一下传统的提交模式。

它是什么？

常规提交 是提交消息的一种简单约定，它遵循一组规则并帮助项目拥有明确且结构良好的提交历史。

如何使用它？

规则非常简单，如下所示，我们有一种提交的类型、提交的上下文（范围）和提交的消息（主题） 。

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

因此，!表示强制属性，?表示可选属性。

主题：祈使句而非过去式

通过这种方式，我们可以告诉我们的团队，如果应用该提交，将会产生什么效果。

“如果应用，此提交将”

“如果应用，此提交将更改标记” ，这比“如果应用，此提交将更改标记”更有意义

类型：提交有哪些类型

类型负责告诉我们正在进行什么改变或迭代，根据约定规则，我们有以下类型：

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

• feat：表示项目新功能的开发。
  例如：添加服务、功能、端点等。

• refactor：用于代码重构，但不会影响系统逻辑/规则的情况。
  例如：代码审查后的代码变更

• style：用于代码格式和样式的更改，但不会以任何方式改变系统。
  例如：更改样式指南、更改 Lint 规范、修复缩进、删除空格、删除注释等。

• fix：用于纠正系统中可能产生 bug 的错误。
  示例：对未按预期运行并返回错误的函数应用处理。

• chore：表示对项目进行的更改不会影响系统或测试文件。这些更改属于开发变更。
  例如：更改 eslint规则、添加 prettier规则、为.gitignore添加更多文件扩展名

• docs：用于项目文档发生变更的情况。
  例如：在 API 文档中添加信息、更改 README 文件等。

• build：用于指示影响项目构建过程或外部依赖项的更改。
  例如：Gulp、添加/删除npm依赖项等……

• perf：表示改进了系统性能的更改。
  例如：将 ForEach 更改为 While，等等……

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

• revert：表示撤销先前的提交。

笔记：

•  每次提交仅一种 类型；

• 类型  是 强制性的；

• 如果您不知道使用哪种类型，这可能是一个很大的变化，并且可以将此提交拆分为两个或多个提交；

• build 和 之间的区别 chore 可能非常微妙，容易造成混淆，因此我们必须注意正确的类型。以 Node.js 为例，我们可以认为，当 中某个开发依赖项的添加/更改时 devDependencies，我们使用 chore。对于项目中常见依赖项的更改/添加，以及对系统有直接实际影响的更改/添加，我们使用 build。

范围：将提交情境化

此时 — — 按照过去的惯例 — — 我们设法了解提交中所做的更改类型 （提交类型），并清楚地了解提交应用后将带来什么（提交主题）。

虽然范围并非强制性的，但它可以用来将提交情境化，减少主体的责任，使其尽可能简洁明了。记住， 范围 必须插入到提交的括号中。

注意：范围必须用/

结论

我写这篇文章是为了记录我的一次学习（它们只是概念应用程序中的一些笔记），但我希望它可以帮助其他开发人员。