通过邮件审查 git 补丁而无需离开 Thunderbird：一种仍然活跃的老派工作流
开发与编程 Jul 20, 2026加入收藏
Korben 重新关注了一种许多年轻开发者完全忽视的工作流程：基于邮件的补丁审查，即 Linux 内核风格的审查。有一个项目可以让你无需离开 Thunderbird 就能完成此操作——而且它比你想象的更有价值。
一个具体案例：为Linux内核、git、Emacs贡献代码
对于只使用过GitHub和GitLab的开发者来说，这个问题可能会显得奇怪：“为什么要通过邮件来审查代码？”具体答案是：因为构建现代计算机基础的大量项目——Linux内核（LKML）、git本身、Emacs、U-Boot、QEMU、Postgres（部分）、大多数BSD项目——并不使用网页代码托管平台来接收贡献。历史悠久的工作流程如下：
- 贡献者执行
git format-patch将分支转换为一系列.patch文件，每个提交对应一个文件。 - 使用
git send-email将这些补丁发送到公开的邮件列表。 - 维护者和同行在邮件中内联回复：他们在引用的代码行前加上
>前缀，并在下方写下评论。这是一种代码审查方式，但通过邮件客户端完成。 - 贡献者发送 v2、v3 等版本。最终某位维护者通过
git am将补丁系列合并。
这种流程具备网页代码托管平台所不具备的客观优势：公开可索引的归档（如 lore.kernel.org、marc.info）、无需GitHub账户即可参与、遵循“一次编写，多次阅读”的原则。
Korben推荐的工具：thunderbird-patch-review
GitHub式审查的舒适度——语法高亮、逐行评论、Approve/Request changes——让一代开发者觉得邮件审查难以阅读。结果是，进入内核贡献的门槛提高了，尽管 git send-email 是一个久经考验的成熟工具。
Marc Coquand 希望让团队采用这种邮件优先的工作流程，同时不强迫大家使用奇特的工具。于是他开发了 thunderbird-patch-review，一个Thunderbird扩展：当收到包含补丁系列的邮件时，扩展会提供一个按钮，打开一个舒适的审查视图——补丁着色、跳转到目标文件、本地应用补丁进行测试、按正确引用规范内联回复。这个工具的目标不是取代GitHub，而是让开发者能够参与那些不使用GitHub的项目，而不必忍受痛苦。
要找到仓库和最新版本，可以参考Korben的文章（链接见来源），其中直接指向Marc Coquand的仓库——而不是引用一个记忆中的URL。
工具链的完整配置
要重建完整的流程（不包括Thunderbird扩展）：
- 在git中配置SMTP：
git config sendemail.smtpServer <服务器>。 - 准备包含cover letter且线程正确的补丁系列：
git format-patch -N HEAD~M，使用 cover-letter（两个连字符后跟cover-letter）和 thread（两个连字符后跟thread）选项。 - 发送补丁系列：
git send-email，使用 to=list@vger.kernel.org 和 cc=maintainer@example.org（每个选项前加两个连字符）。 - 接收端：使用
git am < email.mbox应用收到的补丁系列。
这是一个完全去中心化的流程，不依赖任何第三方。参考文档是 git-scm.com 上的 git send-email(1)。
要点
- 邮件工作流程既未消亡也非边缘：它是内核、git、Emacs、BSD的工作方式。
- Marc Coquand 的 thunderbird-patch-review 让习惯GitHub的开发者能够参与这些项目，无需完全改变工作方式。
- 尝试方法：配置一个外发SMTP账户，尝试用
git send-email提交一个简单贡献（例如内核文档中的错别字——LKML对干净的首次补丁意外地友好）。 - 哲学层面的收获：这也是一个提升Git素养的有用练习——理解邮件补丁和Git提交几乎是同一个对象，这能帮助理解Git的许多行为。
本文由人工智能撰写，并经人工编辑审核。
