git创建和应用补丁的流程【教程】

林译川

2026-10-28 • 👁 0人浏览过

git format-patch生成含提交元数据（作者、时间、消息）的邮件格式.patch文件，适用于正式合入；git diff生成无元数据的.diff文件，仅记录内容差异，适合临时共享未提交修改。补丁不是“导出代码”，而是记录“怎么改的”——用错命令或忽略上下文，补丁很可能打不上、打歪、或丢掉作者和提交信息。 git format-patch 和 git diff 生成的补丁有什么区别？两者都输出

.patch

或

.diff

文件，但内容和用途完全不同：

git format-patch

生成的是「邮件格式补丁」：包含提交哈希、作者、日期、提交信息，甚至签名。适合跨团队分发、保留完整历史，

git am

能直接还原成带元数据的提交。

git diff

（不带参数）只对比工作区与

HEAD

，输出纯差异；

git diff --staged

对比暂存区与

HEAD

。这类补丁不含元数据，

git apply

可用，但

git am

会报错

fatal: Not a valid commit message

。如果目标是快速共享未提交的修改（比如临时给同事看一个 bug 修复），用

git diff > fix.patch

最轻量；如果是准备合入主干的正式改动，必须用

git format-patch

。 git apply 和 git am 应该选哪个？关键看你要不要「自动提交」和「保留原始作者信息」： Git 程序猿必备版本控制工具下载

git apply fix.patch

：只修改文件，不创建提交，也不动暂存区。你需要自己

git add

git commit

。适合测试补丁是否能干净应用，或只想拿改动内容而不关心来源。

git am 0001-*.patch

：不仅应用修改，还会读取补丁里的作者、时间、提交信息，自动生成新提交。适用于接收

git format-patch

产出的补丁，尤其在 CI 流水线或维护者审核后合入时。容易踩的坑：

git am

要求补丁路径与当前仓库结构严格匹配（比如补丁里写

a/src/string.py

，你仓库里就得有

src/string.py

）。而

git apply

支持

--directory=

参数做路径偏移，更灵活。补丁打不上去？先检查这三件事报错常见但原因集中，别急着手动改文件：运行

git apply --check fix.patch

：不实际修改，只验证能否应用。失败时会明确指出哪行/哪个文件不匹配。检查基础版本是否一致：补丁是基于

commit A

生成的，目标仓库当前

HEAD

必须是

A

或其祖先。用

git merge-base HEAD

可确认是否有共同祖先。空白符或换行符干扰：Windows/Linux 换行符混用、IDE 自动 trim 空格，都可能让

git apply

拒绝。加

--ignore-whitespace

参数试试，或用

git apply --whitespace=fix

自动修正。补丁的本质是「上下文敏感的文本替换」，不是万能胶。最常被忽略的是：它不解决逻辑冲突（比如两个补丁都改了同一函数的返回值），只解决行号/内容位置的匹配问题。真要集成多处变更，还是得靠

git rebase

或

git cherry-pick

——补丁只是过渡手段，不是替代分支协作的方案。

相关文章