提交信息格式

Source: Dev.to

提交信息格式

每条提交信息由 标题（header）、正文（body） 和 页脚（footer） 组成。标题采用特殊格式，包含 类型（type）、可选的 范围（scope） 和 主题（subject）：

<type>(<scope>): <subject>

标题是必需的；范围是可选的。

示例 – fix: remove unused dependency lodash.camelcase

提交信息的任何行都不得超过 100 个字符。这可以保证在 GitHub 和各种 Git 工具中阅读友好。

类型（Type）

必须是以下之一：

• feat：新功能。
• fix：错误修复。
• docs：仅文档更改。
• style：不影响代码含义的更改（空格、格式、缺少分号等）。
• refactor：既不修复错误也不添加功能的代码更改。
• perf：提升性能的代码更改。
• test：添加缺失的测试。
• chore：对构建过程或辅助工具、库的更改（例如文档生成）。
• ci：对 CI 配置文件和脚本的更改。
• build：影响构建系统或外部依赖的更改（例如 gulp、broccoli、npm）。
• revert：回滚之前的提交。
• wip：进行中的工作；该提交可能稍后被移除。

范围（Scope）

范围是可选的，可用于指明代码库中受影响的区域，例如 nsis、mac、linux 等。

主题（Subject）

主题应简洁描述更改内容：

• 使用祈使句、现在时（例如 “change”，而不是 “changed” 或 “changes”）。
• 不要 大写首字母。
• 不要 以句号结尾。

正文（Body）

• 使用祈使句、现在时。
• 说明更改的动机，并与之前的行为进行对比。

页脚（Footer）

页脚用于：

• 破坏性更改 – 以 BREAKING CHANGE: 开头，后跟一个空格或两个换行。
• 引用此提交关闭的 GitHub issue（例如 Closes #123）。

最佳实践

• 编写有意义的提交信息 – 清晰传达更改了什么以及为什么。
• 保持提交粒度小 – 每个提交应代表单一的逻辑更改。
• 使用分支 – 为每个功能或错误修复创建新分支。
• 在合并功能分支前 压缩提交（squash），保持历史整洁。
• 提交前审查 – 确保代码符合项目规范并通过测试。
• 自动化测试 – 对每次提交运行自动化测试，及早捕获回归。
• 遵循统一风格 – 按照项目的风格指南保持一致性。

参考文献

• FreeCodeCamp. (2022, March 2). How to write better Git commit messages. https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
• Beams, C. How to write a Git commit message. https://cbea.ms/git-commit/
• 2my. (2021, October 30). Git conventional commits. https://blog.2my.xyz/2021/10/30/git-conventional-commits/