提交规范 是做什么的？
概述
Jarrett 规则的第 4 条：一项变更只包含其逻辑上必需的提交。审查者阅读的是每个变更的干净提交，而不是尝试过程的历史记录。注释要简短。
commit-check 钩子在 git commit 消息超出限制时会发出警告。它不会阻止提交，而是由你来修正该提交。
何时使用
- 每次提交前。
- 每次推送前。
- 当你为了修复一个问题而进行了多次提交时。
- 当
commit-check钩子发出警告时。
流程
1. 编写提交信息
- 主题：不超过 72 个字符。使用祈使语气：例如使用“添加规则钩子”，而不是“已添加规则钩子”。
- 正文：不超过 5 行。如果主题已足够，则省略正文。
- 说明更改了什么以及为什么更改。不要逐一描述每个文件。
- 使用简化英语。参见
simplified-english技能。
2. 每个逻辑变更只进行一次提交
- 一个逻辑变更：审查者可以作为一个整体接受或拒绝的功能切片、修复或重构。
- 不要在一次提交中混入重构和行为变更。
- 不要提交每一次尝试。只有在变更有效且测试通过后才进行提交。
3. 在推送前压缩修正性提交
修正性提交用于更正同一变更中较早的提交。例如：“fix typo”、“wip”、“address review”。
- 使用
git commit --fixup <sha>创建修正性提交。 - 无需编辑器进行压缩：
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base>。 - 如果变基因冲突而停止，修复文件并运行
git add <files>。然后运行GIT_EDITOR=true git rebase --continue。要停止，运行git rebase --abort。 - 再次运行测试。
- 检查结果：
git log --oneline <base>..HEAD。
如果最后一个提交是需要修正的提交，请使用 git commit --amend --no-edit。
警告：不要重写已经推送到共享分支上的提交。请先询问用户。重写会迫使每个团队成员重置他们的历史。
4. 保持注释简短
- 仅在代码含义不清晰时才编写注释。
- 通常一行就够了。说明原因，而非做什么。
- 不要在注释中记录变更历史。Git 已经保存了历史。
常见合理化说辞
| 合理化说辞 | 现实情况 |
|---|---|
| “小的提交能展示我的进度。” | 审查者需要的是结果，而非过程。压缩那些尝试性的提交。 |
| “详细的信息能提供更多上下文。” | 冗长的信息没人会读。把上下文放在规格说明或 PR 中。 |
| “我会稍后压缩。” | “稍后”就是推送之后。请在推送前完成压缩。 |
| “钩子只是警告，所以限制是可选的。” | 限制是团队规则。钩子发出警告是为了让你能够修正它。 |
警示标志
git log在推送前显示“wip”、“fix”、“oops”或“try again”。- 一个错误修复有多个提交。
- 提交正文列出了每个更改过的文件。
- 注释只是重复代码本身的内容。
验证
- 每个主题不超过 72 个字符，并使用祈使语气。
- 每个正文不超过 5 行。
-
git log --oneline <base>..HEAD显示每个逻辑变更对应一个提交。 - 推送前没有残留的修正性提交。
- 任何变基操作后测试均通过。
已知限制：钩子不会检查 git -C <dir> commit 或 git -c <key>=<value> commit。它还会跳过某些无法读取的提交信息，例如通过 -F <file> 指定的信息。