我们常会看到开源项目里提交代码记录中包含一些feat、fix、chore等等，而有些不规范的在提交时也不会区分什么，直接写下提交信息，下面我就拿 mybatis-plus 项目来介绍下。
Git 提交规范有助于提高代码的可维护性和团队协作效率。
一、提交信息结构
1. 标题
- 简短描述本次提交的主要内容，一般不超过 50 个字符。
- 使用祈使句，以动词开头，如 “添加功能”,“修复错误”,“优化性能” 等。
- 避免使用模糊或不具体的词汇，如 “一些修改”,“小调整” 等。
2. 主体
- 如果需要，可以在标题后面添加一个空行，然后详细描述本次提交的内容。
- 说明本次提交的背景、目的和解决的问题。
- 列出具体的修改内容，包括新增的文件、修改的文件和删除的文件。
- 如果有相关的 issue 或任务编号，可以在主体中提及，以便于跟踪和关联。
3. 结尾
- 如果有需要，可以在主体后面添加一个空行，然后添加一些结尾信息。
- 例如，可以列出本次提交的影响范围、注意事项或需要其他开发者关注的问题。
- 也可以感谢其他开发者的贡献或提供反馈的渠道。
二、提交信息格式
1. 使用英文描述
- 为了便于国际团队协作和交流，建议使用英文描述提交信息。
- 如果需要使用中文，可以在英文描述后面添加中文注释。
2. 遵循特定的格式
- 可以使用一些特定的格式来描述提交信息，以便于自动化工具的处理和分析。
- 可以使用 “[类型] 描述” 的格式，常见类型有feat（新功能）、fix（错误修复）、docs（文档修改）、style（代码格式调整）、refactor（代码重构）、perf（性能优化）、chore （杂项，如构建过程或辅助工具的变动）、build（构建系统或外部依赖项的变更）、revert（回滚）、test（添加或修改单元测试）等。
- 规范示例：commit message = subject + ：+ 空格 + message主体。 例如： feat：
增加用户注册功能
3. 避免使用特殊字符和表情符号
- 提交信息应该是清晰、简洁和专业的，避免使用特殊字符和表情符号。
- 特殊字符和表情符号可能会在不同的系统和工具中显示不一致，导致理解困难。
三、提交频率
1. 小步提交
- 尽量避免一次性提交大量的代码，而是采用小步提交的方式，每次提交只包含一个小的功能或错误修复。
- 小步提交可以使代码的变化更加清晰和易于理解，也便于其他开发者进行审查和合并。
2. 及时提交
- 不要等到代码完全完成后再提交，而是在完成一个小的功能或错误修复后，及时提交代码。
- 及时提交可以避免代码丢失或冲突，也便于其他开发者了解你的工作进度。
3. 避免频繁提交
- 虽然及时提交很重要，但也不要过于频繁地提交代码，以免给其他开发者带来不必要的干扰。
- 可以在完成一个相对完整的功能或错误修复后，再进行提交。
四、提交前的检查
- 代码审查
- 在提交代码之前，应该进行自我审查，确保代码的质量和正确性。
- 可以使用一些代码审查工具，如 SonarQube、Checkstyle 等，来检查代码的规范性和潜在的问题。
- 测试
- 在提交代码之前，应该进行充分的测试，确保代码的功能和性能符合要求。
- 可以使用一些自动化测试工具，如 JUnit、TestNG 等，来进行单元测试和集成测试。
- 解决冲突
- 如果在提交代码时发现冲突，应该及时解决冲突，确保代码的完整性和一致性。
- 可以使用一些版本控制工具，如 Git、SVN 等，来解决冲突。
总之，遵循良好的 Git 提交规范可以提高代码的质量和可维护性，也有助于团队协作和项目管理。在实际工作中，应该根据团队的具体情况和需求，制定适合自己的 Git 提交规范，并严格遵守。
