git commit 规范
git commit 规范是团队协作中非常重要的部分,它可以帮助团队成员更好地理解代码的历史变更、快速定位问题,并维护代码库的整洁性。以下是一些常见的 git commit 规范:
1. Conventional Commits 规范
Conventional Commits 是一种流行的规范,适用于需要自动生成变更日志、版本号管理的项目。它要求提交信息遵循以下格式:
1 | <type>[optional scope]: <description> |
主要部分说明
<type>:提交的类型,常见的有:feat:新功能(feature)fix:修复错误(bug fix)docs:文档更新style:代码格式化(不影响代码运行的变动)refactor:代码重构(既不是新功能也不是修复错误)test:测试相关(如添加或修改测试用例)chore:构建过程或辅助工具的变动
[optional scope]:可选的范围,用于指定提交影响的范围(如模块名或文件名)。<description>:简短描述提交的内容,建议控制在 50 个字符以内。[optional body]:详细描述,可以进一步解释提交的动机、解决的问题等。[optional footer]:用于引用问题编号、关闭 issue 等。
示例
1 | feat: add new user authentication feature |
2. Angular Commit Message Conventions
Angular 团队也有一套类似的规范,它在 Conventional Commits 的基础上更详细地定义了提交类型和格式:
1 | <type>(<scope>): <subject> |
主要部分说明
<type>:提交类型,如feat、fix、docs等。(<scope>):作用范围,通常是一个模块或文件名。<subject>:简短描述,建议使用祈使句。<body>:详细描述,可以解释为什么要这么做。<footer>:用于引用 issue 编号、Breaking Change 等。
示例
1 | feat(user-auth): add OAuth 2.0 authentication |
3. 一般性提交规范
如果你的项目没有严格遵循上述规范,也可以采用以下通用的提交规范:
- 提交信息清晰简洁:尽量用简短的语句描述提交的主要内容,避免使用模糊的词汇。
- 使用祈使句:如“Add new feature”而不是“Added new feature”。
- 分层提交:将一个大的功能拆分成多个小的提交,每个提交只解决一个问题。
- 避免冗长的提交信息:如果需要详细说明,可以在提交信息中引用相关的文档或 issue 编号。
- 遵循项目约定:如果项目有特定的提交规范,务必遵守。
4. 工具支持
为了帮助团队成员遵循提交规范,可以使用一些工具:
- Commitizen:一个命令行工具,可以引导开发者按照规范输入提交信息。
- Husky + Commitlint:Husky 可以在提交时运行脚本,Commitlint 可以校验提交信息是否符合规范。
5. 其他建议
- 提交前检查代码:确保代码已经通过测试,没有明显的错误。
- 合理使用分支:将功能或修复放在独立的分支上,提交后再合并到主分支。
- 保持提交历史清晰:避免频繁的合并冲突和复杂的提交历史。
通过遵循这些规范,可以大大提高代码的可维护性和团队协作效率。