撰写 Git 提交信息的最佳方式：像专业人士一样

当开发者回溯查看六个月前的工作内容时，很多时候他不理解为什么做了特定的提交，唯一的原因是因为他没有遵循正确的提交信息编写方式。

\ 全球开发者都在实践提交信息标准，遵循流行标准是很好的做法，这样当你在很长时间后回来查看或其他人查看你的提交信息时，它们不会看起来很尴尬！

\

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

\ 一个优秀的Git提交信息应该有适当的风格、内容和元数据。

\ 一个常见的Git提交遵循这种约定：

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

\ <type>可以是以下之一：

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

\ 你也可以添加自定义类型，这取决于你的团队遵循的标准。上述标准是由ESLint团队遵循的。你可以在这里查看他们的提交信息。

\ 范围是可选的，而信息部分应包含一个单行语句，不超过72个字符，总结提交的目的。

\ 许多开发者也使用信息作为主题行并添加正文；这基本上是提交的描述，但只要你能理解上下文（提交的内容和原因），单行提交信息是更可取的。如果提交需要更详细的描述而无法在单行中解释，提交正文总是必要的。

\ 你也可以使用像Glitter或Commitizen这样的工具来标准化你的提交信息。

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

\ 很多时候，行业专家使用他们的JIRA或Click Up工单作为提交信息，这样一切都可以随时链接或追溯，代码库对未来的开发者保持可维护性。

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

\ 最后，重要的是你的提交信息应该有意义，不会让你的同事开发者或未来的开发者对特定更改的内容感到困惑。

\ 如果你希望了解更多关于常规提交、语义提交或行业遵循的实践，这里有一些资源供你参考：

1. 常规提交
2. 语义提交
3. CBeams的如何编写提交信息

\