git am错误：“0”；“修补程序不适用”；

我正在尝试使用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". 

我使用的是Windows7和最新的git版本“1.9.4.msysgit.1”

另外，在谷歌搜索了几个小时后，我几乎找不到解决办法，但没有任何办法对我有效：

---

给出奇怪的“sha1信息”错误：

---

给出如上所述的第一个错误：“错误：补丁失败：index.php:17”，但未在

index.php

中添加冲突标记

什么是补丁？ 一个补丁（见下文）比一系列说明更简单：“在这里添加这个”、“在那里删除那个”、“将第三个东西更改为第四个”。这就是git告诉您的原因：

您可以在您最喜爱的查看器或编辑器中打开该修补程序，在您最喜爱的编辑器中打开要更改的文件，然后“手动应用”修补程序，使用您知道的（git不知道）来确定当要更改的文件看起来很少或与之前更改的文件完全不同时如何“在此处添加此修补程序”，将这些更改作为补丁交付给您

多一点 三方合并引入的信息比普通的“指令系列”要“多一点”：它还告诉您文件的原始版本是什么。如果您的存储库具有原始版本，git可以将您对文件所做的操作与补丁程序对文件所做的操作进行比较

正如您在上面看到的，如果您请求三方合并，git在另一个存储库中找不到“原始版本”，因此它甚至无法尝试三方合并。因此，您不会得到冲突标记，并且必须手动执行修补程序

使用

--拒绝

当您必须手动应用补丁时，git仍有可能自动为您应用大部分补丁，并且只将少数部分留给有能力对代码进行推理的实体（或任何需要修补的实体）。添加
--reject
告诉git这样做，并将补丁的“不适用”部分保留在拒绝文件中。如果使用此选项，则必须手动应用每个失败的修补程序，并确定如何处理被拒绝的部分

完成所需更改后，您可以
git添加修改后的文件，并使用
git am--continue
通知git提交更改并继续下一个补丁

如果无事可做怎么办？
由于我们没有您的代码，我无法判断是否是这种情况，但有时，您最终会看到其中一个修补程序在拼写已被修复的情况下说出相当于“修复第42行上的单词拼写”的内容

在这种情况下，在查看了补丁和当前代码之后，您应该对自己说：“啊哈，应该完全跳过这个补丁！”这时您可以使用git已经打印的其他建议：

如果运行
git am--skip
，git将跳过该修补程序，因此如果邮箱中有五个修补程序，它将只添加四个提交，而不是五个（或者如果跳过两次，则添加三个而不是五个，依此类推）。
git format patch
还具有
-B
标志

手册页中的描述还有很多需要改进的地方，但用简单的语言来说，在对文件进行完全重新写入之前，补丁将遵循阈值格式（通过删除所有旧文件，然后插入所有新文件）

这对我来说非常有用，因为手工编辑太麻烦了，而且源代码比目标代码更权威

一个例子：

git format-patch -B10% --stdout my_tag_name > big_patch.patch
git am -3 -i < big_patch.patch

git格式补丁-B10%--stdout my\u tag\u name>big\u patch.patch
git am-3-i
我遇到了这个错误，通过使用以下方法可以克服它：
patch-p1

我从这里取的：
有几个模块抱怨修补程序不适用。我遗漏了一件事，那就是树枝已经不新鲜了。在
git merge master
之后，使用
git diff master BRANCH>file.patch
生成补丁文件。去香草分支可以用git apply文件应用补丁。补丁
我也遇到了同样的错误。我在创建修补程序时还原了提交版本。它的工作原理与之前的补丁相反

[mrdubey@SNF]$git日志65f1d63
提交65F1D636315853F2B7070E0E6D99B116BA2B018
作者：Dubey Mritunjaykumar

日期：2019年1月22日星期二12:10:50+0530
提交E377AB50081E3A8515A75A3F7D7C5C98A975C6
作者：Dubey Mritunjaykumar
日期：周一1月21日23:05:48 2019+0530

使用的早期命令：git diff new_commit_id..prev_commit_id>1 diff

获取错误：修补程序失败：文件名：40

工作一：git diff prev_commit_id..latest_commit_id>1。diff
我也有同样的问题。我用过

git format-patch <commit_hash>

git格式修补程序

创建修补程序。我的主要问题是，由于一些冲突，修补程序失败了，但我在文件内容中看不到任何合并冲突。我使用了
gitam--3way
来应用补丁

应用修补程序的正确命令应为：

git am --3way --ignore-space-change <patch_file_path>

git am--3way--忽略空间更改

如果执行上述修补命令，则如果修补应用失败，将创建合并冲突。然后，您可以修复文件中的冲突，就像解决git merge的合并冲突的方法一样，这种错误可能会导致
The copy of the patch that failed is found in:
c:/.../project2/.git/rebase-apply/patch

If you prefer to skip this patch, run "git am --skip" instead.

git format-patch -B10% --stdout my_tag_name > big_patch.patch
git am -3 -i < big_patch.patch

git format-patch <commit_hash>

git am --3way --ignore-space-change <patch_file_path>