如何像专业人士一样编写 Git 提交消息！

当开发人员回过头去寻找他六个月前做过的事情时，很多时候他不明白为什么做出那个特定的提交，唯一的原因是他没有按照正确的方式来写提交信息。

世界各地的开发人员都在实践提交消息标准，遵循流行的标准是很好的，这样当你经过一段时间后回来或其他人查看你的提交消息时，它就不会显得令人尴尬！

告知其他开发人员变更内容的最有效方法是使用精心编写的 Git 提交消息。

团队应该首先决定一个提交消息约定，指定他们正在构建的产品的版本控制历史。

优秀的 Git 提交消息应该具有适当的样式、内容和元数据。

已知的 Git 提交遵循以下约定：

<type>(<scope>): <message>

<type>可以是下列之一：

• feat以获得新功能。
• refactor用于重构生产代码，例如重命名函数。
• docs对文档进行更改。
• fix为用户修复错误。
• perf以提高性能。
• style格式更改、缺少分号等。
• test用于添加缺失的测试、重构测试。
• build用于更新构建配置、开发工具或其他与用户无关的更改。

您还可以添加自定义类型，具体取决于您的团队遵循的标准。ESlint 团队遵循上述标准。您可以在此处查看他们的提交信息。

范围是可选的，消息部分应包含一行语句，不超过 72 个字符，以概括提交的目的。

许多开发人员还将消息用作主题行并添加正文，这基本上是提交的描述，但只要您可以说明上下文（提交什么和为什么），一行提交消息是更好的选择，如果提交需要更详细的描述，而无法在一行中解释，则提交正文始终是必要的。

您还可以使用Glitter或Commitizen等工具来标准化您的提交信息。

不仅如此，您可能还想知道是否有一个工具可以检查您的提交信息，如果不符合指南，则会弹出错误。Commit Lint就是其中之一。它可以帮助您的团队遵守提交约定。

很多时候，行业专家使用他们的 JIRA 或 Click Up 票作为提交消息，以便所有内容都可以随时链接或追溯，并且代码库仍然可以为未来的开发人员维护。

有些团队也喜欢在提交信息中添加表情符号。我整理了一份表情符号及其含义的列表，你可以在这里查看。

最后，重要的是您的提交信息应该有意义，并且不会让您的同事或未来的开发人员对特定更改的含义感到困惑。

如果您想了解有关常规提交、语义提交或行业遵循的实践的更多信息，这里有一些资源供您参考：

1. 常规提交

2. 语义提交

3. 如何通过 CBeams 编写提交消息