Github提交规约

Mttao 收录于类别 Git

2025-05-08 2025-05-08 约 1538 字预计阅读 4 分钟

在协作软件开发中，一个组织良好且易于理解的提交历史是无价的。采用标准化的提交信息格式不仅能增强可读性，还能简化项目的进展。开源开发者大部分都是参考AngularJS的提交规范,以这个作为范本。本文将介绍一种广为接受的方法来构建您的GitHub提交,以提高协作效率。

标准化的提交信息通常由三个不同的部分组成，并用空行隔开：

标题行对于快速理解提交的目的很重要。它遵循特定的结构：

<类型>(<范围>): <主题>

类型 (必需): 定义提交的类别。它必须是以下预定义类型之一：
- feat: 新功能。
- fix: Bug 修复。
- perf: 提升性能的代码更改。
- refactor: 既未修复错误也未添加功能的代码更改（例如，重命名变量）。
- docs: 仅文档更改。
- style: 不影响代码含义的更改（空格、格式、缺少分号等）。
- test: 添加缺失的测试或更正现有测试。
- build: 影响构建系统或外部依赖项的更改（示例范围：gulp、broccoli、npm）。
- revert: 撤销先前的提交。
- ci: 对 CI 配置文件和脚本的更改（示例范围：Travis、Circle、BrowserStack、SauceLabs）。
- chore: 不修改 src 或 test 文件的其他更改（例如，更新 grunt 任务）。
- release: 创建一个新版本。
- workflow: 对自动化工作流程的更改。
范围 (可选): 这提供了额外的上下文信息，并括在圆括号中。它可以指定受更改影响的代码库部分，例如 global、common、route、component、utils 或 build。例如：fix(parser)。
主题 (必需): 这是对提交目的的简明摘要。它应该简短，理想情况下不超过 50 个字符，并以完成以下句子的方式书写：如果应用此提交，它将主题。

提交信息的正文是您可以提供有关更改更详细说明的地方。它应该解释更改背后的动机，并将其与以前的行为进行对比。这部分可以跨越多行，并且在必要时可以在这里详细说明所做的具体修改和开发思路。不要长篇大论，注意要简洁明了。

页脚主要用于两个目的：

重大更改 (Breaking Changes): 任何引入重大 API 更改的提交都必须在页脚中明确指出，以 BREAKING CHANGE: 开头，后跟对更改、理由和迁移说明的描述。也可以在标题中的类型/范围后添加 !（例如，feat(api)!: send an email to the customer when a product is shipped）以进一步突出显示重大更改。
问题引用 (Issue Referencing): 如果提交涉及或关闭了项目问题跟踪器中的特定问题，您应该在此处引用它们（例如，Closes #234，Fixes #123, #456）。

虽然约定式提交的结构化类型为提交提供了清晰的分类，但合理使用Emoji可以进一步增强提交信息的可视性和快速识别性。例如：

为确保一致性并遵守这些规范，强烈建议自动执行提交信息验证。像Husky这样的工具可以与Git的pre-commit钩子集成，以在提交信息最终确定之前检查它们是否符合定义的格式。

总结

通过采用这些GitHub提交规范，开发团队可以显著改善其工作流程，增强协作，并维护一个清晰、易于理解且有价值的提交历史。