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

我正在把我的主人转到舞台分支

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 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". 

我说：“不要叫我”愚蠢“，只是做我告诉你做的！”

我们现在处于僵局。 谁是对的，我如何解决这个问题？

Answer 1

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

没有保证提交没有其他文件没有冲突，应该合并。 git rebase --skip会丢失这些文件。 你不要那个。

希望这可以帮助。

Answer 2

当所有其他的失败，阅读信息。

此修补程序正在尝试修改两个文件，但它们已被删除; 再次删除他们什么也没做。

只要运行git rebase --skip 。

Answer 3

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

我靠：

• 删除现有的文件，
• 在一个不同的文件中对一个注释做单个字符改变
• “git add”是不相关的变化。

Git又开心了。 🙂

Answer 4

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

考虑到这个错误也可能发生，如果你樱桃采摘/移植/ backporting影响重新考虑或重命名文件的变化。

例如，假设您有一个名为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
       b /
         MyOtherClass.java

现在，让我们假设你有一个1.5版的function分支，你试图将其支持到基于support/1.0的function分支。 在该提交中，发布版本1.5（ MyClass.java ， ANewClass.java和MyOtherClass.java ）中的所有三个文件都发生了更改。

如果您尝试使用rebase或plain cherry pick来帮助后台端口，可能会发生以下两种情况之一：

• 如果文件被重新命名为正在移植的更改的一部分，或者正在移植的更改的直接父提交中，GIT的内置重命名检测可能会捕获这些文件是具有原始名称的文件的后代，并且只需应用更改到原始文件。

• 如果文件在版本1.5的历史logging中被重新命名得足够远（在1.0版本发布之后），GIT会告诉你这些文件在release/1.0被删除了，因为它不知道1.0中的文件与1.5 。

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

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