git代码提交对commit-msg的规范

git代码提交对commit-msg的规范:

在 .husky 下配置 commit-msg脚本，内容如下:
npx --no -- commitlint --edit $1

分析:

npx --no -- commitlint --edit $1


让我们逐部分详细分析这个命令:
  
1. `npx`:
   - 这是Node.js生态系统中的一个工具,用于执行npm包中的二进制文件。
   - 使用`npx`的好处是,它可以执行本地安装的包,而不需要全局安装或直接修改PATH。
   - 在这个上下文中,它用来运行`commitlint`命令。
  
2. `--no --`:
   - 这是`npx`的一个特殊选项。
   - `--no`告诉`npx`不要自动安装缺失的包。
   - 双破折号(`--`)是一个shell约定,用来表示选项的结束。这确保后面的所有内容都被视为命令参数,而不是`npx`的选项。
  
3. `commitlint`:
   - 这是实际要执行的命令。
   - `commitlint`是一个用于检查Git提交信息是否符合特定格式的工具。// 这里其实就是 @commitlint/cli 这个工具, 可以运行 npx commitlint --help 查看支持的参数
  
4. `--edit $1`:
   - `--edit`是`commitlint`的一个选项,指示它应该检查一个文件的内容。
   - `$1`是一个shell变量,代表传递给脚本的第一个参数。
   - 在Git hooks上下文中,`$1`通常是Git自动创建的临时文件的路径,该文件包含了提交信息。
  
这个命令的执行流程:
1. 当开发者创建一个新的Git提交时,Husky会触发这个hook。
2. Git会创建一个临时文件,包含提交信息,并将其路径作为第一个参数传递给hook脚本。
3. Hook脚本使用`npx`来运行本地安装的`commitlint`。
4. `commitlint`读取并检查Git提供的提交信息文件。
5. 如果提交信息符合预定义的规则,`commitlint`会允许提交;否则,它会阻止提交并显示错误信息。
  
使用这种方式的优点:
- 确保使用项目本地安装的`commitlint`版本,避免全局版本可能造成的不一致。
- 不需要修改PATH或使用相对路径来执行`commitlint`。
- `--no`选项防止`npx`在`commitlint`不存在时尝试安装它,这可能会导致意外行为。

这个设置帮助团队维护一致的提交信息格式,提高代码库的可维护性和可读性。如果你想了解如何自定义`commitlint`规则或整合到其他工作流程中,我可以提供更多信息。

commit-msg hook 给了我们一个机会在提交完成之前检查和potentially修改提交信息。
commit-msg hook 实际上是在 pre-commit hook 之后运行的。它的主要目的是检查提交信息的格式和内容，而不是检查代码本身。
这种设计允许我们：
首先检查代码质量（在 pre-commit 中）
然后保证提交信息的质量（在 commit-msg 中）
这样的顺序确保了both代码和提交信息都符合项目的标准before完成提交。
相关配置：
1>可以直接在package.json下配置
"commitlint": {
  "rules": { // 更多规则参考: https://commitlint.js.org/reference/rules.html
    "subject-case": [
      0, // 提示级别
      "always" // 本来还应该有第三个参数的，就是subject-case 支持的value, 因为配置了 0 ，所以就不用配置了
    ]
  },
  "extends": [
    "@commitlint/config-conventional" // 关于 conventional 规则参考 https://www.conventionalcommits.org/en/v1.0.0/
  ]
}

2>可以生成一个配置文件commitlint.config.js
{
  "commitlint": {
    "rules": {
      "subject-case": [0, "always"]
    },
    "extends": [
      "@commitlint/config-conventional"
    ]
  }
}

上面配置分析: 这个配置定义了项目中commitlint的行为。让我解释一下这个配置的各个部分：

"rules" 对象：这里定义了特定的commitlint规则。在这个例子中，只有一个规则被显式定义：
```
"subject-case": [
  0,
  "always"
]
```
- "subject-case" 是规则的名称，它控制提交消息主题（第一行）的大小写。
- [0, "always"] 是规则的配置：
  - 0 表示这个规则被禁用（0 = off, 1 = warning, 2 = error）
  - "always" 是规则的附加配置，但因为规则被禁用，所以这里没有实际效果
这个配置实际上是关闭了对主题行大小写的限制，允许开发者使用任何大小写格式。
"extends" 数组：
```
"extends": [
  "@commitlint/config-conventional"
]
```
这表示项目的commitlint配置扩展了 @commitlint/config-conventional 包。这是一个常用的预设配置，它实施了Conventional Commits规范。
Conventional Commits是一种提交消息的格式约定，通常看起来像：
```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

综合分析：

1. 这个项目使用了Conventional Commits规范作为基础。
2. 但是，它关闭了对主题行大小写的限制，这可能是为了给开发者更多的灵活性。
3. 除了 `subject-case` 规则，其他所有来自 `@commitlint/config-conventional` 的规则都会被应用。

官方文档: https://commitlint.js.org/

总结:
commitlint 的核心功能和用途：
  
1. 主要功能：
   - commitlint 主要用于检查 Git 提交信息（commit messages）的格式和内容。
  
2. 目的：
   - 确保项目中所有的提交信息遵循一致的格式和约定。
   - 提高代码库的可维护性和可读性。
   - 便于自动化工具（如生成更新日志）处理提交历史。
  
3. 工作原理：
   - 通常通过 Git hooks（特别是 commit-msg hook）集成到工作流中。
   - 在每次提交时自动运行，检查提交信息是否符合预定义的规则。
  
4. 常见用途：
   - 强制实施 Conventional Commits 规范。
   - 确保提交信息包含必要的信息（如类型、范围、描述等）。
   - 限制提交信息的长度、格式或使用的词语。
  
5. 可配置性：
   - 可以通过配置文件（如我们之前讨论的 package.json 或 commitlint.config.js）自定义规则。
   - 可以扩展预设配置（如 @commitlint/config-conventional）并覆盖特定规则。
  
6. 与其他工具集成：
   - 经常与 Husky 等工具配合使用，以自动化执行检查。
   - 可以集成到 CI/CD 流程中，确保所有提交（包括通过 UI 创建的）都符合规范。
  
7. 好处：
   - 帮助团队保持一致的提交风格。
   - 使得理解项目历史和生成变更日志变得更容易。
   - 促进更好的协作和代码审查流程。

总的来说，commitlint 是一个强大的工具，用于维护高质量、一致的 Git 提交历史。它不仅仅是简单的检查，而是帮助团队建立更好的沟通和协作实践。

参考官网: https://commitlint.js.org/reference/configuration.html (主要两种方式，本文采用的是第二种)