我最喜欢的 Git commit（2019）

原文 ↗ Hacker News 讨论 ↗

一个仅修改一个字符、移除配置文件中非 ASCII 空白的微小修复，引发了关于开发者应当在 Git commit 信息上投入多少精力的更广泛讨论。许多人认为，结构良好且信息丰富的 commit 信息对未来的调试、代码考古和审查极其重要，尤其是在 issue 跟踪器或 wiki 消失、或难以搜索时；也有人反驳说，冗长的叙述式信息很少有人会读，应该放到单独的文档或 PR 中，而且工具通常只显示第一行。讨论还涉及“智能”Unicode 字符破坏工具链、squash merge 和糟糕的历史维护习惯的影响，以及需要更好的界面来让历史上下文更容易找到并使用。

智能引号、Unicode，以及“gremlin”字符

  • 许多人回忆起因智能引号和配置或源文件中的非 ASCII 空白字符而导致的故障（常常来自 Outlook、macOS 编辑器、TextEdit、Notes）。
  • 有些人认为，排版引号和不同空白必须是不同的码点，这对语言和排版很重要；另一些人则说，过度语义化的 Unicode 是设计错误，样式应该由字体来处理。
  • 关于软件是否应该自动转换智能引号存在争论，而本地化引号规则和语言检测又让这件事变得很困难。
  • 现在有几位用户依赖 IDE 高亮、pre-commit 钩子、键位重映射或编辑器配置来防止或暴露这些字符。

详细 commit 信息的价值与风格

  • 许多人称赞示例 commit：上下文丰富、对微妙 bug 的解释清晰，并且记录了调试过程。
  • 也有人觉得这过于“长篇大论”；他们希望有简洁的摘要（尤其是第一行），理想情况下采用 BLUF/TL;DR 风格，细节可放在下面。
  • 常见建议结构：用简短的 subject 说明问题和范围，然后用段落解释当前行为、原因和新行为。

Commit 信息与其他文档

  • 一派人认为 commit 信息是关键且持久的文档——尤其是在多年后做 blame/历史考古时，或者 Jira/Confluence 之类系统消失时。
  • 另一派人更倾向于把深入的设计理由放在 issue、PR 描述或 markdown 文档中，因为 commit 信息是不可变的，也更难进行协作式完善。
  • 大家普遍同意，commit 信息应更多记录“为什么”，而不是“是什么”；diff 已经展示了代码改动。

工具、工作流与可发现性

  • 几位指出，常见工具和托管代码平台通常只展示第一行，因此长正文的利用率很低。
  • 有人认为 Git 和 GUI 让历史探索过于繁琐，导致人们不太依赖 commit 信息；也有人回应说，好的编辑器/CLI 工具（blame、log、magit、IDE 集成）其实很好用。
  • squash merge 和寿命很长、杂乱的分支被批评为会破坏有用历史，并鼓励“检查点”式 commit。
  • 大家对糟糕的错误信息和对无效编码的薄弱校验感到沮丧；更好的工具本可以完全避免这个 bug。

提到的实用建议

  • 使用编辑器配置、语法高亮或钩子来标记非 ASCII 空白。
  • 倾向于原子化、作用范围清晰且消息有意义的 commit；把 commit 信息当作“写给未来自己的笔记”。
  • 不要只依赖外部跟踪器或 PR；可以把它们链接起来，但要把关键上下文保留在代码附近或历史中。