结论：git format-patch生成的补丁才真正适合Git项目间传递；git diff输出的patch只改内容，不带作者、时间、提交信息，不能被git am直接应用。
直接说结论：用 git format-patch 生成的补丁才真正适合 Git 项目间传递；git diff 输出的 patch 只能改内容，不带作者、时间、提交信息，别误当完整补丁用。
什么时候该用 git format-patch 而不是 git diff
你希望别人合入修改时，保留原始 commit author、date、subject 和 Signed-off-by 签名 —— 就必须用 git format-patch。它输出的是 mbox 格式邮件补丁（含 From 行、空行分隔、三连横线分隔 commit message 和 diff），git am 才能还原成一次真实提交。
- 只导出最近 1 次提交：
git format-patch -1 - 导出某次提交及之后所有（不含该次）：
git format-patch de85add5 - 导出两个分支差异（如 feature 分支独有的提交）：
git format-patch origin/main..HEAD - 指定输出目录：
git format-patch -3 --output-directory=./patches
注意：git diff 生成的 fix.patch 没有这些元数据，git am fix.patch 会报 error: no email was found。
git diff 生成 patch 的适用场景和坑点
它适合快速分享「尚未提交的改动」或「临时验证变更效果」，但本质只是文本 diff，不是 Git 提交快照。
- 未暂存修改 →
git diff > unstage.patch - 已暂存未提交 →
git diff --cached > staged.patch - 某次提交 vs 其父提交 →
git diff HEAD~1 HEAD > single.patch
关键限制：
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 必须在仓库根目录执行，否则路径错位（比如在
src/下跑git diff，patch 里是main.c，但目标仓库期待src/main.c） - 默认不处理新建/删除文件，加
-N参数才安全：git diff -N --cached - 不能用
git am导入，只能用git apply或系统patch命令
应用补丁前必须检查的三件事
打补丁失败，90% 出在这三个地方，不是 patch 写得不对，而是环境没对齐。
- 换行符：Windows 和 Linux 混合开发时，
^M会导致patch does not apply。统一关掉自动转换：git config core.autocrlf false - 子模块：如果 patch 修改了 submodule，
git apply默认忽略，得加--submodule参数，且目标仓库.gitmodules必须存在且路径匹配 - 二进制文件：patch 含图片、编译产物等？
git apply默认拒绝，必须显式加--binary
验证是否能干净应用，先跑：git apply --check fix.patch，返回非零码就说明有冲突或路径问题。
git apply 和 git am 到底怎么选
一句话区分：git apply 是“改代码”，git am 是“重演提交”。
- 用
git apply：只想看 patch 效果、CI 预检、或目标仓库不需要保留原始历史（比如内部测试分支）；它不碰 index 和 HEAD，失败也不污染工作区 - 用
git am：要合入外部贡献、需保留 author 信息、后续要git blame追溯 —— 但要求 patch 是git format-patch产出的 mbox 格式 - 冲突时：
git am --abort中止，git am --continue继续，git am --skip跳过当前 patch
最容易被忽略的是：即使你用 git format-patch -1 生成单个 patch，如果目标分支已有相同 patch（通过 --ignore-if-in-upstream 检测），git am 会静默跳过 —— 不报错也不提示，得自己核对 commit hash。
