常规提交，Git 的未来

传统的提交彻底改变了我的工作方式，并让我重新思考如何处理我的 git 工作流程。

什么？

简单来说，约定式提交就是编写提交信息的标准。就像变量命名或版本号的约定一样，提交信息的编写也有一定的约定。

更简单地说，常规提交会告诉您如何编写提交消息。

它们更容易编写

采用约定式提交有很多好处。但采用者首先注意到的是，它简化了编写提交的过程。所有开发者都知道命名事物有多难，而编写描述性强但简洁的提交则更加困难。约定式提交提供了一种可遵循的格式，省去了编写提交信息时所需的大量思考工作，并为我们指明了正确的方向。

它们更容易阅读

其次，它们让人类和计算机都能更轻松地读取仓库的历史记录。这种约定的妙处在于，它旨在让维护人员能够轻松地浏览提交，并了解每个人对仓库所做的操作。当gitmoji 的加入使这一切变得更加容易。

好的，那么 gitmojis 是什么？

Gitmojis是一种在开发背景下赋予表情符号意义的惯例（是的，另一种惯例）。

例如：

• 🎨 = “改进代码的结构/格式。”
• ⚡️ =“提高性能。”
• ✨ = “介绍新功能。”

这些表情符号让查看提交所做的更改更加容易，因为它们色彩鲜艳，能立即吸引读者的注意。即使是不熟悉这种格式的人也能理解其含义，因为人类会将含义与图像联系起来。

工具可以解析它

约定使自动化工具能够轻松处理提交。一些工具可以用来检查提交、帮助编写提交，甚至自动化变更日志和版本控制。

我被说服了，惯例是什么？

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

这是该约定的基本表示，以扩展巴科斯范式 (Extended Backus-Naur Form) 表示。更多规则和解释请参阅约定提交网站。

类型

提交类型描述了发生的工作类型。您可以将其视为类似于添加到问题或故事的标签。

该约定定义了feat一些功能和fix错误修复，但可以根据需要添加其他内容。例如，commitlint增加了以下几个：

• ci
• 家务
• 文档
• 壮举
• 使固定
• 性能
• 重构
• 恢复
• 风格
• 测试

范围（可选）

范围代表您正在执行工作的范围，因此完全取决于正在进行的项目。范围通常以 包围( )。如果发生了重大变更，有时!会在范围末尾添加 来表示。

例如，一个 Web 应用程序可能具有：

• （数据库）
• （依赖项）
• （造型）

描述

这是提交描述的位置。它是对已完成工作的简短描述。任何与更改相关的 gitmoji 都应该放在此处的开头。

主体（可选）

如果需要，可以在此处添加更详细的描述。如果本次提交引入了重大变更，则必须在此处或页脚进行解释，格式如下：
BREAKING CHANGE change description

页脚（可选）

页脚再次完全依赖于项目，但它们必须遵循特定的格式，“每个页脚必须由一个单词标记，后跟一个:<space>或<space>#分隔符，再后跟一个字符串值组成。”（来自常规提交网站）

示例

（由常规提交网站提供）

feat: ✨ allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

refactor!: 💥 drop support for Node 6

BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.

fix: ✏️ correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z
Refs #133

结论

传统的提交很好，你应该尝试一下。