介绍
在版本控制方面，Git 是一个非常有效的工具。然而，像任何其他工具一样，你必须正确使用它才能充分发挥其作用。你需要考虑不同的方面。本文着重介绍如何按照传统提交规范（Conventional Commits specification）编写有效的 Git 提交信息。它概述了基本原则，帮助你创建清晰、信息丰富且标准化的提交信息。
良好提交信息的样子
发送消息的目的是为了沟通。为了使沟通有效，接收者必须清楚地理解发送者想要传达的信息。一个commit message包括三个部分，每部分提交说明尽量不要超过100个字符，避免自动换行展示影响美观。
- Header 必须
- Body 可以省略
- Footer 可以省略
<type>[<scope>]: <subject>
// 空一行
<body>
// 空一行
<footer>
1. type类型（必选）
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
2. scope范围（可选）
虽然提供范围是可选的，但为了清晰起见，最好包括它。范围指定了代码库中受更改影响的部分，从而帮助读者理解更改的上下文。这在有很多贡献者的大型项目中特别有用。它使协作更容易。
feat[xxx功能]: xxxxx
3. subject描述（必需）
这是描述你所做内容的部分。保持简洁明了。确保你用祈使句写。例如，不要写“Added authentication mechanism”，而应该写“Add authentication mechanism”。这将提高自动生成的变更日志和发布说明的可读性。
4. body正文（可选）
这里你可以提供更多关于你实现的信息。使用空行将正文与描述分开。
5. footer页脚（可选）
如果你想包括任何元数据，可以在页脚中进行。例如，如果你所做的更改解决了之前提出的问题，可以通过引用编号在这里指出。例如：fix #003。你也可以在页脚中包括审阅者的名字。
记住，范围后面应加冒号和空格，然后再给出描述。当在页脚中包含 BREAKING CHANGE 时，应注意其大小写敏感，需全部大写。
示例
feat: add support for dark mode.
chore(Art_func): change variable “Empty” to “empty”
Change variable name from “Empty” to “empty” for consistency with
the naming convention.
fix(database)!: modify schema
Modify schema to accommodate only structured data. Dismiss all
other types of data.
提交的信息比较长，一行不够使用git commit，会打开一个交互式的窗口填写编辑信息
对于简单的信息提交可以使用git commit -m “subject” -m “body”
总结
编写的提交信息要和代码变更相关，为了使其清晰和信息丰富，建议至少包含你所做更改的类型和描述。遵循传统方法以维护支持协作和各种流程自动化的良好代码库。了解更多的详细信息，请务必查看传统提交规范。
