我正在尝试使用git将多个提交从一个项目移动到第二个类似的提交。
所以我创建了一个包含5个提交的补丁：
git format-patch 4af51 --stdout > changes.patch
然后将补丁移动到第二个项目的文件夹，并想要应用补丁：
git am changes.patch
...但它给了我错误：
Applying: Fixed products ordering in order summary.
error: patch failed: index.php:17
error: index.php: patch does not apply
Patch failed at 0001 Fixed products ordering in order summary.
The copy of the patch that failed is found in:
c:/.../project2/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
所以我打开了index.php，但没有任何改变。我假设有一些>>>>>>>标记等，就像解决合并冲突时一样，但文件中没有标记冲突。 git status还向我提供了已更改文件的空列表（仅changes.patch存在）。所以我运行git am --continue，但会出现另一个错误：
Applying: Fixed products ordering in order summary.
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
我正在使用Windows 7和最新的git版本＆＃34; 1.9.4.msysgit.1＆＃34;
P.S。经过几个小时的谷歌搜索，我找到了一些解决方案，但没有什么对我有用：
git am -3 changes.patch
给出了奇怪的＆＃34; sha1信息＆＃34;错误：
Applying: Fixed products ordering in order summary.
fatal: sha1 information is lacking or useless (index.php).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Fixed products ordering in order summary.
The copy of the patch that failed is found in:
c:/.../project2/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
git am changes.patch --ignore-whitespace --no-scissors --ignore-space-change
给出如上所述的第一个错误：＆＃34;错误：补丁失败：index.php：17＆＃34;，但未添加index.php中的冲突标记。
答案 0 :(得分：87)
补丁比一系列说明更多（见下文）：＆＃34;在此添加＆＃34;，＆＃34;删除那里＆＃34;，＆＃34;将第三件事改为a第四＆＃34 ;.那个为什么 git告诉你：
The copy of the patch that failed is found in: c:/.../project2/.git/rebase-apply/patch
您可以在自己喜欢的查看器或编辑器中打开该补丁，在您喜欢的编辑器中打开要更改的文件，然后手动应用＆＃34;补丁，使用你知道的（而git没有）找出如何＆＃34;在这里添加这个＆＃34;当要更改的文件现在看起来很少或什么都不像他们之前更改时所做的那样，这些更改将作为补丁发送给您。
三方合并引入了＆＃34;更多＆＃34;信息比普通＆＃34;系列指令＆＃34;：它告诉你文件的原始版本是什么。如果您的存储库具有原始版本，那么您的git可以将您所做的事情与文件进行比较，以及补丁对该文件所做的事情。
如上所述，如果您请求三向合并，git无法找到＆＃34;原始版本＆＃34;在另一个存储库中，它甚至无法尝试三向合并。因此，您不会获得任何冲突标记，并且必须手动执行补丁程序。
--reject 当您必须手动应用修补程序时，git仍然可以自动为您应用大部分修补程序，只留下一些具有该功能的实体推理代码（或任何需要修补的代码）。添加--reject会告诉git这样做，并让＆＃34;不适用＆＃34;拒绝文件中补丁的一部分。 如果您使用此选项，您仍必须手动应用每个失败的补丁，并找出如何处理被拒绝的部分。
完成所需的更改后，您可以git add修改后的文件并使用git am --continue告诉git提交更改并转到下一个修补程序。
由于我们没有您的代码，我无法判断是否是这种情况，但有时候，您最终会找到其中一个补丁来说明相当于的事情，例如＆＃34;修正第42行和第34行的单词拼写;当那里的拼写已经修好了。
在这种特殊情况下，你看过补丁和当前的代码，应该对自己说：＆＃34; aha，这个补丁应该完全被跳过！＆＃34;当你使用已打印的其他建议git时，那就是：
If you prefer to skip this patch, run "git am --skip" instead.
如果您运行git am --skip，git将跳过该补丁，这样如果邮箱中有五个补丁，最终只会添加四个提交，而不是五个（如果你有三个，则为三个而不是五个跳过两次，依此类推。）
答案 1 :(得分：4)
Form Details:
Full Name: [text-471]
Email: [email-326]
Phone: [phone-007]
也有git format-patch标志。
手册页中的描述还有很多不足之处，但在简单的语言中，它是阈值格式 - 补丁将在完全重写文件之前遵循（通过删除所有旧文件，然后是单个插入所有新内容。）
当手动编辑过于繁琐时，这对我来说非常有用，而且来源比我的目的地更具权威性。
示例：
-B答案 2 :(得分：2)
我有这个错误，能够通过使用以下方法克服它：
patch -p1 < example.patch
我从这里拿走了它： https://www.drupal.org/node/1129120
答案 3 :(得分：2)
我有同样的问题。我用过
git format-patch <commit_hash>
创建补丁。我的主要问题是补丁由于某些冲突而失败，但是我看不到文件内容中的任何合并冲突。我曾经使用git am --3way <patch_file_path>来应用补丁。
应用补丁的正确命令应该是：
git am --3way --ignore-space-change <patch_file_path>
如果执行上述命令进行修补，则如果应用修补失败，则会产生合并冲突。然后，您可以解决文件中的冲突，就像解决 git merge
的合并冲突的方法一样答案 4 :(得分：1)
这种错误可能是由LF与CRLF线路末尾不匹配引起的，例如当您查看补丁文件时，您绝对确定它应该可以应用，但是不会。
要对此进行测试，如果您有仅适用于一个文件的补丁，则可以尝试在该文件上运行'unix2dos'或'dos2unix'（尝试两个，看看哪个文件导致文件更改；您可以可以获取Windows和Unix的这些实用程序），然后将该更改作为测试提交提交，然后再次尝试应用补丁。如果可行，那就是问题所在。
NB git am默认情况下将补丁应用为LF（即使补丁文件包含CRLF），因此，如果要将CRLF补丁应用到CRLF文件，则必须使用{{1} }，按照this answer。
答案 5 :(得分：0)
有几个模块抱怨补丁不适用。我错过的一件事是树枝变得陈旧。 git merge master使用git diff master BRANCH > file.patch生成补丁文件之后。转到香草分支可以使用git apply file.patch
答案 6 :(得分：0)
我遇到了同样的错误。创建补丁时，我还原了提交版本。它的工作方式与早期补丁相反。
[mrdubey @ SNF] $ git log 65f1d63 提交65f1d6396315853f2b7070e0e6d99b116ba2b018 作者：杜比（Dubey Mritunjaykumar）
提交e377ab50081e3a8515a75a3f757d7c5c98a975c6 作者：杜贝·穆里坦贾伊库马尔（Dubey Mritunjaykumar） 日期：2019年1月21日星期一23:05:48 +0530
以前使用的逗号：git diff new_commit_id..prev_commit_id> 1 diff
错误：补丁失败：文件名：40
工作方式之一：git diff prev_commit_id..latest_commit_id> 1.diff