1、Commit的原则

  1. 原子性(Atomicity)：每次提交应该包含一个独立、完整的变更集。尽量避免在一次提交中包含多个不相关的变更。这样可以使提交更加清晰、易于理解和回滚。
  2. 描述性的提交信息：提交信息应该简明扼要地描述所做的变更。使用命令式语言,如"Add new feature"，"Fix bug in login page"等，而不是"Changes made"。提交信息应该能让其他开发者理解你做了什么改动。
  3. 及时提交：不要一次性提交大量的变更。尽量在完成一个小的功能或修复一个问题时立即提交。这样可以更好地跟踪代码变更历史，并方便进行代码审查和回滚。
  4. 单一职责：每次提交应该只做一件事。如果你同时修复了两个问题或添加了两个新功能，请拆分成两次单独的提交。这样可以使提交历史更加清晰。
  5. 版本号规范：遵循语义化版本控制的规范，如 major.minor.patch 的格式。这有助于理解代码的变更情况和兼容性。
  6. 提交范围：提交的范围应该尽可能小。不要在一次提交中修改多个文件或多个模块。这样可以更容易定位问题，并方便进行代码审查。
  7. 提交频率：保持适当的提交频率。不要过于频繁地提交，也不要一直推迟提交。一般来说，在完成一个小的功能或修复一个问题后即可提交。
  8. 提交消息模板：可以使用提交消息模板，包含标题、描述、变更类型等，以保持提交信息的一致性。
  9. 签名提交：使用 GPG 密钥对提交进行签名，可以增加提交的可信度。

2、为什么要有commit规范

定义规范的好处有：

  1. 可读性和可维护性：一致的 commit 格式和有意义的 commit 信息可以使提交历史更加清晰、可读和易于理解。当需要查找、回滚或分析代码变更时，良好的 commit 记录将大大提高效率。
  2. 协作和团队协作：在团队协作中，每个人都应该遵循相同的 commit 规范。这可以确保提交记录的整体一致性。当其他开发人员需要理解或修改你的代码时，清晰的 commit 记录将有助于他们快速理解代码变更。
  3. 自动化工具的支持：许多工具(如 CI/CD 系统、代码审查工具等)依赖于 commit 信息来执行自动化任务，如生成变更日志、触发构建和部署等。
  4. 代码回滚和 bug 追踪：当需要回滚代码或调试 bug 时，良好的 commit 记录将提供宝贵的上下文信息,帮助开发人员更快地定位问题所在。
  5. 版本管理和发布：遵循 Semantic Versioning 的 commit 规范可以更好地反映代码的变更类型(major/minor/patch)。这有助于确定版本号，并为发布管理提供依据。

3、Commit提交格式

一个常见的 commit 提交格式如下:

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

<body>

<footer>

其中各部分的含义如下:

  1. type：用于指示提交的类型，如 feat(新功能)、fix(bug 修复)、docs(文档变更)、style(代码格式变更)、refactor(重构)、perf(性能优化)、test(添加测试)等。

  2. scope：用于指示变更影响的范围，如特定模块/组件的名称。这部分可以省略。

  3. subject：提交信息的标题,简要描述变更的内容。推荐使用命令式语气,如"Add new feature"而不是"Added new feature"。

  4. body：提供更详细的提交信息描述，解释为什么需要做这些变更，以及变更的影响。可以省略。

  5. footer：可以包含一些额外的信息，如关闭的 issue 编号、重大变更等。可以省略。

下面是一个示例:

feat(login): Add new login functionality

- Implement email and password-based authentication
- Add social login options (Google, Facebook)
- Improve error handling and feedback

Closes #42

这个提交描述了一个新的登录功能，包括了电子邮件/密码登录和社交登录的实现，以及错误处理的改进，同时它关闭了 Issue #42。

4、相关工具和插件

4.1、Commitizen

Commitizen是一个撰写合格 Commit message 的工具。

安装命令如下：

pnpm i -D commitizen

然后，在项目目录里，运行下面的命令：

commitizen init cz-conventional-changelog --pnpm --save-dev --save-exact

执行命令之后，会在package.json中生成以下配置：

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

使用git cz提交代码

git cz

image-20240625145904669

刚开始使用确实会有些不习惯，不过强制自己跟着规范走，养成习惯了就好了

当然也可以手动规范的去填写，这列出了一些通用的提交类型

类型描述
build编译相关的修改
chore新增依赖库、工具，或者构建流程变化
ci持续集成
docs文档相关修改
feat新特性、新功能
fix修复Bug
perf性能提升、体验优化
refactor代码重构
revert回滚
style代码格式优化
test测试用例修改

4.2、Commitlint

Commitlint是一个类似validate-commit-msg 的工具，主要用于检查 Node 项目的 Commit message 是否符合格式。

首先安装 @commitlint/cli 和 @commitlint/config-conventional ：

pnpm i -D @commitlint/cli @commitlint/config-conventional
  • @commitlint/cli 是commitlint提供的命令行工具
  • @commitlint/config-conventional是社区中一些共享的配置

可以创建 commitlint.config.js文件来管理配置：

export default {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "type-enum": [
      2,
      "always",
      ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"]
    ],
    "type-case": [0],
    "type-empty": [0],
    "scope-empty": [0],
    "scope-case": [0],
    "subject-full-stop": [0, "never"],
    "subject-case": [0, "never"],
    "header-max-length": [0, "always", 72]
  }
}

可以配合Husky一起使用，初始化 Husky：

npx husky install

添加 commit-msg 钩子, 创建一个 .husky/commit-msg 文件，其内容类似于：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
npx npx --no-install commitlint --edit "$1"

此时输入不规范的commit：

git commit -m 'edit md'

image-20240625165216250

再调整为规范的commit

git commit -m 'docs(README.md): edit md'

image-20240625165415314