Как оформить заказ на конкретный коммит во время Git Rebase

Question

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

Я хочу найти коммит, в котором функциональность существующей функции была изменена,Я хотел начать с проверки последнего коммита до того, как начал писать свой код в первый раз, чтобы убедиться, что существующая функция действительно была изменена.Но когда я пытаюсь проверить другой коммит, я получаю сообщение об ошибке, сообщающее, что мне нужно объединить файлы с текущего шага в моем слиянии, и что мне нужно сначала разрешить мой текущий индекс.Но я не могу разрешить свой текущий индекс, пока не выясню, как была изменена существующая функция.Что мне делать?

Answer 1

Два комментария, которые у вас есть (пока, по крайней мере), являются ключами для продвижения вперед.

Фон

Пауза (по любой причине, включая интерактивную опцию "править").rebase имеет рабочее дерево в режиме detached HEAD .Это немного деликатное состояние, и неразумно нарушать настройку HEAD здесь (что будет делать git checkout какой-либо другой ветви или коммита).

Перебазировка, которая была приостановлена ​​из-за конфликта слияния,еще хуже: он не только включает режим отсоединенного HEAD, он имеет index в конфликтном состоянии.Поскольку индекс имеет решающее значение для фиксации, то, что вы можете сделать с этим рабочим деревом only , это либо исправить конфликт и продолжить, либо прекратить перебазирование и вернуть все обратно, как вы начали.

Вы не хотите делать это: вы хотите закончить ребаз, потому что:

Я потратил много времени, работая над ребазом, и я почти закончил.

Решение, таким образом, состоит в том, чтобы получить другое рабочее дерево.

Получить другое рабочее дерево

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

Тамбыло несколько ошибок, найденных в git worktree с момента его выпуска 2.5;Я бы избегал использовать его слишком интенсивно до тех пор, пока около Git 2.15 или около того, * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * просто поменьшеОднако версия Git 2.5 подойдет.

Если ваш Git более ранний, чем 2.5, или вы нервничаете из-за вышеуказанной ошибки, вы можете просто клонировать существующий репозиторий.Клоны занимают немного больше дискового пространства и времени, чем добавленные рабочие деревья, но не намного больше, и они работают в каждой версии Git.

---

¹ Iсам был укушен этой самой ошибкой.Однако стоит отметить, что безвредно, если ваши объекты (те, которые git gc могут считать не имеющими ссылок) моложе времени истечения срока действия чернослива, которое по умолчанию составляет 14 дней.Короткоживущие побочные рабочие деревья будут склонны не вызывать эти git worktree ошибки (эта и ряд других исправлены между 2,5 и 2,15).