删除/修改冲突后，Git rebase 将不会继续答案

【问题标题】：Git rebase will not continue after a delete/modify conflict删除/修改冲突后，Git rebase 将不会继续
【发布时间】：2011-07-27 20:20:02
【问题描述】：

我正在将我的主人变基到阶段分支

git checkout stage
git rebase master

有一次我删除了两个文件，然后根据 GIT 修改了这两个文件。

warning: too many files, skipping inexact rename detection
CONFLICT (delete/modify): test-recommendation-result.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation-result.php left in tree.
CONFLICT (delete/modify): test-recommendation.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation.php left in tree.
Failed to merge in the changes.
Patch failed at 0015.

我想说“是的 git，继续删除那些文件”所以 ....

git rm test-recommendation-result.php
git rm test-recommendation.php
git rebase --continue

Git 说：

Applying [Bug] Fix test recommender
No changes - did you forget to use 'git add', Stupid?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

我说“别叫我‘笨蛋’，照我说的做！”

我们现在处于对峙状态。谁是对的，我该如何解决这个问题？

【问题讨论】：

git 也称我为愚蠢

标签： git version-control rebase git-rebase

【解决方案1】：

执行git add -A，然后执行git rebase --continue。这应该会添加所有更改 - 包括删除文件，然后继续。

不能保证提交没有其他不冲突的文件应该合并。 git rebase --skip 会丢失这些文件。你不想这样。

【讨论】：

一般来说你是对的，但在这种情况下，我们似乎可以推断不存在其他变化。 Git 要么抱怨其他冲突，要么rebase --continue 会起作用。
你没有抓住重点。这里的第一步是“检查 git status 的输出”。如果它没有列出任何冲突，并且没有上演，那么跳过是正确的选择 - 正如 OP 所见，添加/继续将什么也不做。如果它只列出了阶段性更改，那么一开始就没有冲突，您可以继续（永远不会问这个问题）。如果有冲突，问题仍然不会被问到，而你的答案很危险——你需要在盲目添加所有内容之前解决冲突。
短版：当 rebase 中途停止时，您不应该始终运行单一的命令序列。您需要了解发生了什么，并采取相应的行动。
我相信你的回答，但我想知道为什么这是真的。为什么仅“git rm”不足以让 git 知道您的意图是确认删除这些文件（并向索引添加删除条目），以及“git rm”之后的“git add”是什么真的是什么意思？
如果您的仓库中有未跟踪的文件，请小心，因为-A 会将它们全部添加。就我而言，冲突发生在子目录中，我刚刚做了git add subdir。

【解决方案2】：

当所有其他方法都失败时，请阅读消息。

此补丁正在尝试修改两个文件，但它们已被删除；再次删除它们没有任何作用。

只需运行git rebase --skip。

【讨论】：

不保证其他文件已正确合并。 rebase skip 会丢失这些更改。
哦，我认为如果其他文件正确合并，rebase 不会抱怨。
问题是它抱怨两个文件有冲突。该提交可能不仅仅包含更改的那两个文件。如果你跳过，你也会跳过那些，而不仅仅是那些报告冲突的。
@adymitruk：这是报告的仅有的两个冲突，所以如果其他文件被更改，它们已经在索引中，rebase --continue 不会抱怨缺少文件。 rebase --skip在这种情况下是完全正确的。
它涵盖了索引中存在和不存在文件且没有冲突的两种情况。见上面的 cmets。

【解决方案3】：

当提交添加了与现有文件冲突的二进制文件时，我遇到了这个问题。

我得到了它：

删除现有文件，
对不同文件中的评论进行单个字符更改，并且
"git add" 进行了不相关的更改。

Git 又开心了。 :)

【讨论】：

【解决方案4】：

没有一种神奇的命令序列可以始终运行来解决这种情况。如果有，GIT 的开发人员只会执行该操作而不会打扰用户。

请考虑，如果您正在挑选/移植/反向移植影响已重构或重命名的文件的更改，也会发生此错误。

例如，假设您有一个名为 support/1.0 的分支，如下所示：

com.somewhere.package-a/ MyClass.java MyOtherClass.java

现在，假设在 1.0 和 1.5 版本之间，这被重构了。所以现在release/1.5 看起来像这样：

com.somewhere.package/ 一种/ MyClass.java ANewClass.java 乙/ MyOtherClass.java

现在，假设您有一个 1.5 版的功能分支，您正尝试将其反向移植到基于 support/1.0 的功能分支。在该提交中，从 1.5 版开始对所有三个文件（MyClass.java、ANewClass.java 和 MyOtherClass.java）进行了更改。

如果您尝试使用变基或纯樱桃选择来帮助进行反向移植，可能会发生以下两种情况之一：

如果文件被重命名为移植更改的一部分，或在更改的直接父提交中移植后，GIT 内置的重命名检测可能会捕捉到这些文件是具有原始名称的文件的后代，并且简单地将更改应用到原始文件。
如果文件重命名的时间足够久远 1.5 版（发布 1.0 版之后），GIT 会告诉你文件在release/1.0 中被删除，因为它没有知道 1.0 中的哪些文件对应于 1.5 的更改。

ANewClass.java 几乎肯定会触发有关已被删除的错误，除非它被添加到正在向后移植的更改之一中。

因此，如果您盲目地遵循一组命令来解决这种情况，代码可能会丢失，这就是 GIT 提示您手动指导的原因。

【讨论】：

【解决方案5】：

作为我的问题：

当我执行git add . 时，我的所有更改都消失了。我需要更改任何文档（只是添加一点更改，例如添加评论）并做git add . 而不是git rebase --continue 为我工作。这是 git 的一个已知错误

【讨论】：

【解决方案6】：

如果你做了像我这样的事情，因为文件应该被忽略而在某些时候它没有被忽略 - 所以它最终进入源代码控制，从文件系统中删除文件，然后中止 rebase。

之后您可以重新启动并且不会出现此错误。

这不是一个理想的解决方案，但不幸的是，一旦发生这种情况，我没有找到任何其他可接受的补救措施。

【讨论】：