Git 提交模式

Git 对我们 Devs 的使用是必不可少的，无论是在个人项目中，还是在多人开源项目或整个社区中。

鉴于此，正确使用 git commit很重要。拥有连贯和标准化的语言有助于参与项目的每个人理解已经发生的变化。

在上图中，我们看到了评论不当的提交有多么有害，因为我们无法理解发生的更改的性质及其上下文。从长远来看，这种影响甚至更具破坏性，因为软件的可维护性由于这些更改范围的不一致以及它们在过去如何影响项目而受到影响。

考虑到这一点，让我们谈谈常规提交模式。

---

它是什么？

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

---

如何使用它？

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

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

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

---

主题：命令式而不是过去式

通过这种方式，我们告诉我们的团队如果应用提交将做什么。

“如果应用，此提交将会改变”

“If applied, this commit will change the markup”，这比“If applied, this commit will changed the markup”更有意义

---

类型：提交的类型是什么

类型负责告诉我们正在进行什么更改或迭代，从约定规则来看，我们有以下类型：

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

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

• refactor：当存在对系统逻辑/规则没有任何影响的代码重构时使用。
  示例：代码审查后的代码更改

• style：当代码格式和样式更改不会以任何方式更改系统时使用。
  示例：更改样式指南、更改 lint 约定、修复缩进、删除空格、删除注释等……

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

• 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.

---

范围：上下文化提交

在这一点上——按照过去的约定——我们设法理解了提交中所做的更改类型 （提交类型），并清楚地了解如果应用提交将带来什么（提交主题）。

尽管范围不是强制性的，但它可以用于将提交上下文化并减少对主题的责任，使其尽可能简洁明了。请记住， 范围 必须插入括号之间的提交中。

注意：作用域必须用/

---

结论

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