主要观点：作者原本以为这会是篇较短的帖子，结果却是最长的，比之前两篇还长。接着指出规范中一些不太喜欢的地方，如提交的格式要求（类型需前缀、描述长度等）、网站（特别是常见问题解答）中的一些内容（如误选提交类型后的处理方式等），最后表示并不完全反对提交消息的标准化，但认为当前的 Conventional Commits 存在一些问题。

关键信息：

• 帖子长度出乎预料。
• 规范中提交格式相关细节及作者看法（类型前缀、描述长度等）。
• 网站 FAQ 中关于误选提交类型的处理及相关建议（git rebase -i 等）及其不足。
• 对 squash 合并的看法及原因。

重要细节：

• 提交类型可为名词、feat、fix 等，后跟可选范围、可选!及必需的冒号和空格。
• git-commit 手册建议提交消息开头不超过 50 字符，而文中 71 字符的描述不符合。
• 页脚令牌用-代替空格，BREAKING CHANGE 为例外。
• 提交类型前缀中破坏变更需用!，可省略页脚中的 BREAKING CHANGE 但应在描述中说明。
• git rebase -i 需在文本编辑器中操作，更倾向有明确指令或链接，且修改最后一个提交消息可用 git comit --amend。
• 不赞同 squash 合并会导致信息丢失及后续需拆分等情况。