- 已经会基本提交和分支操作的开发者
- 想理解命令边界与风险的人
Command Reference
git-send-email 教程
将 `format-patch` 产出的补丁序列按邮件线程发送给维护者或邮件列表，适用于内核式补丁协作流程。
- 知道工作区、暂存区、提交的基本关系
- 能读懂 `git status` 和简单历史图
- 误把本地整理命令用到共享历史
- 在没确认恢复路径前直接继续改写历史
一句话理解
git send-email 用于把补丁序列按邮件格式发送出去，并保留提交边界与讨论线程。
典型使用场景
- 邮件列表驱动的开源协作
- 维护者要求 patch-by-email 流程
- 无法直接访问托管平台的环境
常见配套流程
git format-patch -3 origin/main
git send-email *.patch
先生成补丁，再发送邮件。
发送前必须确认
- SMTP 配置与认证可用
- 收件人（To/Cc）准确
- 线程关系（主题前缀、回复链）符合维护者要求
- 补丁顺序与 cover letter 完整
更稳的发送方式
先小范围 dry-run 或发送给自己验证：
git send-email --dry-run *.patch
常见失败点
- 邮件编码/换行导致补丁损坏
- 主题前缀不符合列表规范
- 丢了某一封中间补丁导致序列断裂
邮件补丁一旦发送到公开列表，修正成本和沟通成本都会变高。先验证格式与线程关系是最低成本保险。
git send-email 把补丁文件作为邮件通过 SMTP 发送到邮件列表或维护者。理解它时，要明确它只负责传输，不修改仓库历史也不更新任何跟踪引用。
接下来建议继续看什么
git-format-patchgit-request-pullopen source fork pr contribution
- 把 format-patch 生成的补丁文件发送到开源项目的邮件列表进行代码评审。
- 在补丁工作流中，作为补丁从本地到达审阅者的最后一步：format-patch 导出，send-email 发送。
- 用
--dry-run预览邮件头和收件人，确认格式正确后再真正发送。
图例理解
补丁文件（.patch）SMTP 配置
已发送的邮件邮件列表中的补丁序列
send-email 只负责传输，不会修改本地仓库的任何内容。
特殊情况与边界
- 真正发送前最好先做
--dry-run或小范围测试，确认收件人、线程关系和编码都正确。 - 需要预先配置 SMTP 服务器信息，可以用
--smtp-server命令行指定或写在 Git 配置中。 - 补丁文件的命名顺序和 In-Reply-To / References 邮件头决定了邮件的线程关系。
- send-email 不修改补丁文件内容，发送前应确保补丁本身格式完整、没有多余的空行或截断。
延伸阅读
继续搭配 git status、git log、git show 一起看，通常更容易判断这条命令对历史、索引和工作区分别造成了什么影响。