Git图形客户端按提交范围导出补丁的操作清单

需要把几个本地提交交给同事、代码评审或另一条分支时，Git图形客户端可以直接把提交序列导出为补丁。本文以 Git Extensions 的 Revision graph 和 Format patch 为例：先确定当前分支，再选中范围内的最新、最旧提交，最后设置输出目录。这样生成的补丁会保留提交说明和 SHA 元信息，接收端还可以继续用 Git 的方式应用。

官方地址：https://gitextensions.github.io/

一、先确认仓库和提交范围

打开 Git Extensions 的仓库窗口，进入 Revision graph。先看顶部当前分支，再沿提交线找到要分享的改动。不要在 detached HEAD 或错误的 release 分支上直接导出，否则补丁文件本身可能没错，范围却已经错了。

第1步：定位最新提交

在提交图中单击范围内最晚的那个提交，也就是希望补丁系列最后包含的提交。随后按住 Ctrl 单击范围内最早的提交。Git Extensions 的文档明确建议先选最新提交、再用 Ctrl 选择最旧提交；连续序列比跳跃选中无关提交更容易保持编号和审阅顺序。

每次点击后都看右侧详情中的提交说明和缩短 SHA。若两端之间夹有合并点或其他人的提交，先回到提交图核对拓扑，不要仅凭提交标题判断范围。

二、在 Format patch 中生成补丁

第2步：打开补丁格式对话框

在选中的提交上打开右键菜单，选择 Create patch，进入 Format patch。在输出方式中选择 Save patches in directory，通过 Browse 指定一个空的专用目录，例如项目外的临时交付目录。目录越明确，越不容易把上一次导出的旧文件误认为本次结果。

确认提交列表仍是本次选择后执行生成。成功状态应能看到按序编号的文件，例如 0001-change.patch、0002-fix.patch。这里的编号表示补丁序列，不代表文件系统的修改时间；移动或重命名输出文件前，先保留原编号。

三、导出后按清单复核边界

Git 的 format-patch 语义是按提交生成补丁邮件格式文件，因此它适合需要保留提交边界的协作场景。合并提交不等同于普通单提交补丁，复杂拓扑应先与接收者约定基线；不要看到文件能生成，就把它当成完整的合并复现包。

四、交给接收端时选择正确的应用方式

接收端若需要把每个补丁恢复成独立提交，可以在 Git Extensions 中选择 Apply patches，或者使用 git am。若只是检查文本差异，才使用 git apply 一类的工作区应用方式。应用前先切到正确分支并保持工作区干净；出现冲突时按接收端的实际基线处理，不要直接覆盖文件。

常见问题

为什么选了两个提交后文件数量不对？

最常见原因是输出目录已有旧补丁，或两端并非同一条连续提交线。换一个空目录重新生成，再按首尾 SHA 复核。

补丁能不能只保留文件差异、不保留提交说明？

可以，但那是另一种交付目标。Format patch 适合保留提交序列；只传文件变化时应明确使用普通 diff，并让接收者知道它不会恢复原提交元信息。

为什么不建议随便选中断开的提交？

中断选择可能让补丁文件不再按连续序列编号，接收者也更难判断依赖关系。除非你明确知道这些提交彼此独立，否则应重新选择连续范围。