Я нахожусь в середине перестановки моего хозяина на ветку этапа
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".
Я говорю: "Не называй меня" глупым "и просто делай то, что я тебе говорил!"
Сейчас мы находимся в противостоянии. Кто прав и как это исправить?
do git add -A, за которым следует git rebase --continue. Это должно добавить все изменения, включая удаление файлов, а затем продолжить.
Нет никакой гарантии, что у коммита не было других файлов, которые не конфликтуют и должны быть объединены. git rebase --skip потеряет эти файлы. Вы этого не хотите.
Надеюсь, что это поможет.
Если все остальное не удается, прочитайте сообщение.
Этот патч пытается изменить два файла, но они уже были удалены; удаление их снова ничего не делало.
Просто запустите git rebase --skip.
Я ударил это, когда коммит добавил двоичный файл, который противоречил существующему файлу.
Я получил его:
Git снова был счастлив.:)
Существует не одна волшебная последовательность команд, которая всегда запускается для решения этой ситуации. Если бы было, 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).
Если вы попытаетесь использовать rebase или простой выбор вишни, чтобы помочь с back-port, может произойти одна из двух вещей:
Если файлы были переименованы как часть пересаживаемых изменений, или между непосредственными родительскими фиксациями изменений, являющихся трансплантированное, GIT встроенное обнаружение переименования может поймать, что эти файлы являются потомками файлов с оригинальными именами и просто применить изменения к исходным файлам.
Если файлы были переименованы достаточно далеко назад в историю
релиз 1.5 (после выпуска версии 1.0), GIT расскажет вам, что
файлы были удалены в release/1.0, потому что это не
знать, какие файлы в 1.0 соответствуют изменениям от 1.5.
ANewClass.java почти наверняка вызовет ошибку об удалении, если только он не был добавлен в одно из изменений, которые были перенесены обратно.
Следовательно, поскольку код может потеряться, если вы слепо следуете одному набору команд для разрешения этой ситуации, почему GIT предлагает вам руководство для руководства.