git am PATCH 失败的处理方法

参考:http://www.cnblogs.com/domainfei/articles/2433504.html

http://blog.sina.com.cn/s/blog_5372b1a301015y0n.html

英文原文地址:http://www.pizzhacks.com/bugdrome/2011/10/deal-with-git-am-failures/


比如,一个典型的git am失败,可能是这样的:
$ git am PATCH
Applying: PACTH DESCRIPTION
error: patch failed: file.c:137
error: file.c: patch does not apply
error: patch failed: Makefile:24
error: libavfilter/Makefile: patch does not apply
Patch failed at 0001 PATCH DESCRIPTION
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

正如你所见,如果冲突发生,git只是输出上述信息,然后就停下来。一个小冲突会导致整个patch都不会被集成。

处理这种问题的最简单方法是先使用 git am --abort,然后手动的添加此patch, patch -p1 < PATCH,手动解决掉代码冲突,最后使用 git commit -a 提交代码。但是这样做有个问题就是你会失去PATCH中原本包含的commit信息(比如From,Date,Subject,Signed-off-by等)。应该有一种更聪明的方法。

在 .git/rebase-apply 目录下,存放着相应的补丁文件,名字是“0001” (在更新的git版本中,存放补丁文件的目录名有所改变,这里使用的git版本是 1.7.4.1)。

事实上,你可以使用 git apply 命令打patch(git apply 是git中的patch命令)。如同使用 patch -p1 命令时一样,然后手动解决代码冲突(检视生成的 .rej 文件,与冲突文件比较,修改冲突内容,并最终把文件加入到index中):

$ git apply PATCH --reject
$ edit edit edit
(译注:根据.rej文件手动解决所有冲突)
$ git add FIXED_FILES
$ git am --resolved

就这么简单!
想多一些解释,好吧。git am 并不改变index,你需要使用 git apply --reject 打patch(保存在 .git/rebase-apply),手动解决代码冲突,(译注:使用 git status 列出所有涉及文件),把所有文件(不仅仅是引起冲突的文件)添加到(git add)index,最后告诉 git am 你已经解决(--resolved)了问题。这样做的好处是你不需要重新编辑commit信息。而且,如果你正在打的是一系列patch(就是说你在打的是多个patch,比如 git am *.patch)你不需要使用 git am --abort,然后又 git am。

<think>嗯,用户想了解Git中生成补丁的具体命令和用法。首先,我需要回忆Git生成patch的常用方法。记得有两种主要方式:git format-patchgit diff。前者生成的是每个commit的独立patch文件,包含提交信息,适合用git am应用;后者生成的是差异文件,可以用git apply应用,但不会保留提交信息。 接下来,应该详细说明这两个命令的具体用法。比如git format-patch的用法是生成从某个提交之后的补丁,或者指定范围。例如,生成最近n个提交的补丁,或者某个commit哈希之后的补丁。同时要提到生成的.patch文件命名规则。 然后是git diff,用于生成工作区或暂存区的差异,比如比较不同分支或不同提交之间的差异,保存为patch文件。需要给出具体的命令示例,比如git diff commit1 commit2 > xxx.patch。 接下来是打patch方法,分为git amgit apply。要解释两者的区别,git am会保留提交信息,适合git format-patch生成的补丁,而git apply只是应用差异,需要手动提交。还要提到冲突解决的情况,比如git am失败后如何继续。 还要注意用户提供的引用内容,特别是引用2中提到git apply和git am的区别,需要准确反映在回答中。另外,引用3提到git am --resolved的使用,这部分在解决冲突后的操作步骤需要包含进去。 可能用户会混淆两种生成patch方法,需要明确区分使用场景。比如需要保留提交历史时用format-patch,只需要代码改动用diff。同时,给出实际例子帮助用户理解,比如生成单个commit的补丁,或者两个commit之间的差异。 最后,检查是否有遗漏的细节,比如多个commit生成多个patch的情况,或者如何指定输出目录。确保步骤清晰,命令准确,符合用户的实际操作需求。还要生成相关问题,帮助用户深入理解,比如如何应用多个patch,或者解决冲突的方法。</think>### Git生成Patch文件的命令及用法 在Git中生成补丁(Patch)文件主要有两种方式:`git format-patch`和`git diff`,分别适用于不同场景。 --- #### 1. **生成单个提交的补丁文件(保留提交信息)** 使用`git format-patch`命令可以生成包含提交元数据(如作者、时间、提交信息)的补丁文件,适用于需要保留完整提交历史的场景。 **命令格式:** ```bash # 生成最近1个提交的补丁 git format-patch -1 <commit_hash> # 生成某个范围内的提交(如从commit1到commit2) git format-patch <commit1>..<commit2> # 生成某个提交之后的所有补丁(如从commit_hash开始) git format-patch <commit_hash> ``` **示例:** ```bash # 生成最近1个提交的补丁,文件名类似0001-commit-message.patch git format-patch HEAD~1 ``` 生成的补丁文件会以`[序号]-[提交信息].patch`的格式命名,可直接用`git am`应用[^2]。 --- #### 2. **生成通用差异文件(仅代码改动)** 使用`git diff`生成普通差异文件,仅包含代码变动,不包含提交信息。适用于临时传递改动或跨仓库应用补丁。 **命令格式:** ```bash # 生成工作区与暂存区的差异 git diff > changes.patch # 生成两个提交之间的差异 git diff <commit1> <commit2> > changes.patch # 生成分支差异(如feature分支与main分支) git diff main..feature > feature.patch ``` --- #### 3. **应用补丁文件** 根据补丁类型选择不同命令: - **`git am`**:用于应用`git format-patch`生成的补丁,保留提交信息。 ```bash git am 0001-commit-message.patch ``` 若补丁冲突,解决冲突后执行: ```bash git am --continue # 或 git am --resolved[^3] ``` - **`git apply`**:用于应用`git diff`生成的补丁,仅合并代码改动,需手动提交。 ```bash git apply changes.patch git add . git commit -m "应用补丁" ``` --- #### 4. **典型场景示例** - **生成多个提交的补丁**: ```bash git format-patch HEAD~3 # 生成最近3个提交的补丁 ``` - **打多个补丁**: ```bash git am *.patch # 批量应用所有补丁 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值