git commit规范

git commit 规范

git commit 规范是团队协作中非常重要的部分,它可以帮助团队成员更好地理解代码的历史变更、快速定位问题,并维护代码库的整洁性。以下是一些常见的 git commit 规范:

1. Conventional Commits 规范

Conventional Commits 是一种流行的规范,适用于需要自动生成变更日志、版本号管理的项目。它要求提交信息遵循以下格式:

1
2
3
<type>[optional scope]: <description>
[optional body]
[optional footer]

主要部分说明

  • <type>:提交的类型,常见的有:
    • feat:新功能(feature)
    • fix:修复错误(bug fix)
    • docs:文档更新
    • style:代码格式化(不影响代码运行的变动)
    • refactor:代码重构(既不是新功能也不是修复错误)
    • test:测试相关(如添加或修改测试用例)
    • chore:构建过程或辅助工具的变动
  • [optional scope]:可选的范围,用于指定提交影响的范围(如模块名或文件名)。
  • <description>:简短描述提交的内容,建议控制在 50 个字符以内。
  • [optional body]:详细描述,可以进一步解释提交的动机、解决的问题等。
  • [optional footer]:用于引用问题编号、关闭 issue 等。

示例

1
2
3
4
feat: add new user authentication feature
This commit adds a new user authentication feature using OAuth 2.0.
It includes the necessary API calls and UI components.
Closes #123

2. Angular Commit Message Conventions

Angular 团队也有一套类似的规范,它在 Conventional Commits 的基础上更详细地定义了提交类型和格式:

1
2
3
4
5
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

主要部分说明

  • <type>:提交类型,如 featfixdocs 等。
  • (<scope>):作用范围,通常是一个模块或文件名。
  • <subject>:简短描述,建议使用祈使句。
  • <body>:详细描述,可以解释为什么要这么做。
  • <footer>:用于引用 issue 编号、Breaking Change 等。

示例

1
2
3
4
5
feat(user-auth): add OAuth 2.0 authentication
This commit adds OAuth 2.0 authentication to the user module.
It includes the necessary API calls and UI components.
Closes #123
BREAKING CHANGE: The old authentication method is removed.

3. 一般性提交规范

如果你的项目没有严格遵循上述规范,也可以采用以下通用的提交规范:

  • 提交信息清晰简洁:尽量用简短的语句描述提交的主要内容,避免使用模糊的词汇。
  • 使用祈使句:如“Add new feature”而不是“Added new feature”。
  • 分层提交:将一个大的功能拆分成多个小的提交,每个提交只解决一个问题。
  • 避免冗长的提交信息:如果需要详细说明,可以在提交信息中引用相关的文档或 issue 编号。
  • 遵循项目约定:如果项目有特定的提交规范,务必遵守。

4. 工具支持

为了帮助团队成员遵循提交规范,可以使用一些工具:

  • Commitizen:一个命令行工具,可以引导开发者按照规范输入提交信息。
  • Husky + Commitlint:Husky 可以在提交时运行脚本,Commitlint 可以校验提交信息是否符合规范。

5. 其他建议

  • 提交前检查代码:确保代码已经通过测试,没有明显的错误。
  • 合理使用分支:将功能或修复放在独立的分支上,提交后再合并到主分支。
  • 保持提交历史清晰:避免频繁的合并冲突和复杂的提交历史。
    通过遵循这些规范,可以大大提高代码的可维护性和团队协作效率。