Git rebase не будет продолжаться после конфликта удаления / изменения

Question

Я нахожусь в процессе перебазирования моего мастера в сценическую ветвь

git checkout stage
git rebase master

Некоторое время я удалял два файла, а затем модифицировал два файла в соответствии с GIT.

Я хочу сказать: «Да, дерьмо, иди и удали эти файлы», так что ...

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

Гит говорит:

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

Я ударил это, когда коммит добавил двоичный файл, который конфликтовал с существующим файлом.

Я получил это по:

• удаление существующего файла,
• внесение одного символа в комментарий в другом файле и
• «добавление мерзавцев», это несущественное изменение.

Гит снова был счастлив. :)

Answer 4

Не существует ни одной волшебной последовательности команд, которая всегда выполнялась бы для разрешения этой ситуации.Если бы это было так, разработчики GIT просто выполнили бы это действие и не стали бы беспокоить пользователя.

Учтите, что эта ошибка также может произойти, если вы выбираете / переносите / переносите изменения, которые влияют на файл, который был повторно проанализированили переименован.

Например, скажем, что у вас есть ветвь с именем support/1.0, которая выглядит следующим образом:

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

Теперь предположим, что между версиями 1.0 и 1.5 это было реорганизовано.Итак, теперь release/1.5 выглядит следующим образом:

    com.somewhere.package/
      a/
        MyClass.java
        ANewClass.java
      b/
        MyOtherClass.java

Теперь предположим, что у вас есть ветвь функций из выпуска 1.5, которую вы пытаетесь перенести обратно в ветвь функций, основанную на support/1.0,В этом коммите произошли изменения во всех трех файлах начиная с версии 1.5 (MyClass.java, ANewClass.java и MyOtherClass.java).

Если вы попытаетесь использовать перебазирование или простой выбор вишни, чтобы помочь со спиной-port, может произойти одно из двух:

• Если файлы были переименованы как часть трансплантируемых изменений, или среди непосредственных родительских коммитов трансплантируемых изменений, встроенная в GITпри обнаружении переименования может обнаружить, что эти файлы являются потомками файлов с оригинальными именами, и просто применить изменения к исходным файлам.

• Если файлы переименованы достаточно далеко назад в историиверсии 1.5 (после выпуска версии 1.0) GIT сообщит вам, что файлы были удалены в release/1.0, поскольку не знает, какие файлы в версии 1.0 соответствуют изменениям версии 1.5.

ANewClass.java почти наверняка вызовет ошибку об удалении, если только она не была добавлена ​​в одно из изменений, переносимых обратно.

Следовательно, потому что кодможет быть потеряно, если вы будете слепо следовать одному набору команд для разрешения этой ситуации, поэтому GIT запрашивает у вас ручное руководство.