删除/修改冲突后，Git rebase 将不会继续
Posted
技术标签:
【中文标题】删除/修改冲突后，Git rebase 将不会继续【英文标题】：Git rebase will not continue after a delete/modify conflict 【发布时间】：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 也称我为愚蠢 【参考方案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 的分支，如下所示：
现在，假设在 1.0 和 1.5 版本之间，这被重构了。所以现在release/1.5 看起来像这样：
现在，假设您有一个 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。
之后您可以重新启动并且不会出现此错误。
这不是一个理想的解决方案，但不幸的是，一旦发生这种情况，我没有找到任何其他可接受的补救措施。
【讨论】：
以上是关于删除/修改冲突后，Git rebase 将不会继续的主要内容，如果未能解决你的问题，请参考以下文章