Git rebase последовательно удаляет изменения

Question

По какой-то причине, каждый раз, когда я пытался использовать rebase, он заканчивал тем, что отбрасывал все мои коммиты ветви функций.Вот пример того, что показывает интерактивная перебазировка на мастер:

pick 05973319 First commit
pick 62341efd Second commit 
pick e1c1a080 Third commit
pick 2b5285f7 Fourth commit

Обратите внимание, что все эти коммиты были сделаны в ветви функций.Теперь, когда я выхожу из интерактивного режима, перебазирование не выполняется из-за конфликтов.Тем не менее, $ git log не показывает ни одной из фиксаций ветви функций.И если я посмотрю на файлы, которые я изменил в ветви функций, все эти изменения были отброшены.

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

Я не понимаю, как такого рода разрешение конфликтов является дистанционно приемлемым.Есть ли какая-то неправильная конфигурация или антипаттерн, который может привести к этому?Обратите внимание, что объединение с $ git merge master всегда работает как положено.

Answer 1

... Теперь, когда я выхожу из интерактивного режима, перебазирование завершается неудачно из-за конфликтов.

Это еще не не удалось . остановлено после применения нуля или более команд pick.

Команда git status в любом современном Git скажет вам, что вы находитесь в интерактивном ребазе, которыйна данный момент еще не закончил.(В старые добрые времена git status не говорил вам таких вещей, и вы просто должны были знать или догадываться.)

$ git log не показывает никаких коммитов ветви функций.

Это говорит о том, что проблема возникла во время самого первого вишневого пика, так что ни один из выбранных коммитов еще не находится в незавершенной, строящейся ветке.То есть, ноль из ваших четырех pick до сих пор удалось.pick 05973319 находится в процессе разработки, и git status сообщит вам, какие файлы требуют ручного массажа, чтобы исправить их, после того, как Git оставил вам беспорядок.

Ваша задача - исправить их - возможно, используябеспорядок, оставленный в вашем рабочем дереве, возможно, с использованием git mergetool и некоторого любимого инструмента слияния;метод зависит от вас.Но вы должны решить проблемы.Исправив их, и, если необходимо, запустите git add, ¹ ваш git status скажет вам, что все конфликты исправлены, и вы должны запустить git rebase --continue, чтобы ребаза завершила этот выбор вишни и пошла дальше.к следующему.Следующий может иметь или не иметь конфликты.Если этого не произойдет, Git завершит это pick самостоятельно и перейдет к третьему, в противном случае все это повторяется.

Этот тип перебазирования нормален , хотя какобычно это зависит от ваших рабочих схем и входных файлов.Некоторые люди сталкиваются с этим постоянно, а некоторые почти никогда.

---

¹ Если вы используете git mergetool, он обычно будет делать соответствующие git add с.Я предпочитаю избегать git mergetool: вместо этого я устанавливаю merge.conflictStyle на diff3 и обычно просто использую мой редактор в беспорядке, оставленном в рабочем дереве.Установка стиля diff3 изменяет размеченный конфликт и включает ввод first или merge-base.Стиль по умолчанию оставляет только секции second , --our и третий --theirs.Исходный код слияния, от которого расходились наша и их версии, поэтому невидим, и это иногда делает конфликты очень трудными для понимания.Но это все дело личного вкуса.