Git Apply技术问题:获取补丁基准版本与二进制文件管理
问题
我基于项目某一特定代码版本制作了包含新增或修改二进制文件的补丁文件,尝试在执行git reset --hard origin/<branch>后的当前代码版本上,使用--3way选项应用该补丁。过程中出现三种情况:部分文件提示“Applied patch to
编辑冲突文件时,我看不到rebase时常见的<<<<<<<和>>>>>>>冲突标记,只能通过读取.diff文件手动复制粘贴修改,操作难度极大。
我认为问题源于补丁制作后代码库已变更,计划先回到补丁的基准版本,再应用补丁,最后执行rebase解决冲突。现在有两个疑问:
git apply不会自动完成回到补丁基准版本的操作吗?如何获取该基准版本?- 回到基准版本后,我已将新增或修改的二进制文件与补丁一起压缩,是否只需将这些文件放到本地仓库对应位置,再执行
git apply即可?
回答
1. git apply不会自动切换到补丁基准版本
git apply的核心逻辑就是把补丁里的改动直接往当前工作区的代码上套,它完全不会帮你切换到补丁基于的原始基准版本——不管你当前在哪个commit,它只看当前文件的内容来尝试合并。
2. 如何获取补丁的基准版本
有两种常用方法:
- 从补丁文件本身提取:如果是用
git diff或git format-patch生成的补丁,文件开头会有index <old-hash>..<new-hash>的行,其中<old-hash>是基准版本的文件哈希;如果是用git diff <base-commit> <your-commit>生成的补丁,<base-commit>就是你要找的基准commit ID。 - 用
git patch-id查找:要是忘了基准commit,先给补丁生成唯一标识:
得到的输出里第一个哈希是补丁ID,接着用git patch-id < 你的补丁文件.patchgit log --grep=<补丁ID>找到补丁对应的commit,这个commit的父节点就是基准版本。
3. 回到基准版本后的正确操作
不用单独放二进制文件再执行git apply,分两种情况:
- 如果生成补丁时加了
--binary参数(比如git diff --binary或git format-patch --binary),补丁里已经包含了二进制文件的完整改动,直接执行git apply --binary 你的补丁文件.patch就能自动处理二进制文件的新增/修改。 - 如果没加
--binary,补丁里可能没包含二进制文件的改动,这时候才需要把二进制文件放到对应目录,然后执行git add把它们加入暂存区,再和补丁里的代码改动一起提交。
推荐完整流程:
- 切换到基准版本:
git checkout <基准commit ID> - 应用补丁:
git apply --binary 你的补丁文件.patch - 验证改动无误后提交:
git add . && git commit -m "应用补丁内容" - 切回目标分支:
git checkout <你的分支名> - 把补丁提交rebase到目标分支最新版本:
git rebase --onto origin/<branch> <基准commit ID> <刚才的补丁提交ID>
(这个过程中Git会正常生成<<<<<<<这类冲突标记,方便你可视化解决冲突)
内容的提问来源于stack exchange,提问作者S. Gougeon
相关产品推荐
相关产品推荐

