Забули "git rebase - продовжувати" та зробили "git". Як виправити?

112

Я передавав код у git, у мене виникли конфлікти злиття. Я вирішив конфлікти і зробив:

git add

У цей момент я забув зробити:

git rebase --continue

Я продовжив кодування і зробив:

git commit

для змін. Зараз я "no branch"вже не можу:

git rebase --continue

Як це виправити?

git

— Абхілаш
джерело

# Зараз немає в жодній галузі. нічого не вчинити (чистий робочий каталог)

— Abhilash

5

РЕДАКТУВАННЯ : Подивіться також на відповідь нижче, щоб побачити, чи це простіше рішення для вас. https://stackoverflow.com/a/12163247/493106

Мені довелося б спробувати це, але я думаю, що це я зробив би:

Позначте останню комісію (або просто запишіть її десь SHA1, щоб не втратити): git tag temp
git rebase --abort
Зробіть ребауз ще раз. Вам доведеться знову вирішити об'єднання. :(
git rebase --continue
git cherry-pick temp

Проблема в цьому полягає в тому, що ваш tempкомітет, ймовірно, містить як дозвіл злиття, так і новий код. Так це може бути складним, але я б спробував це і побачив, чи працює він.

— MatrixFrog
джерело

Ви можете позначити тег, як каже @MatrixFrog, або можете зберегти його як патч. Потім зробіть ребауз аборту. Перевірте стан, щоб переконатися, що РЕПО перебуває у стані, за яким ви знаєте, що не було проблем, а потім запустіть завантаження та перезавантаження.

— yasouser

17

Не робіть цього. Дивіться відповідь kirikaza нижче для набагато простішого / чистішого способу. Не возиться з вишневим вибором та вирішенням конфліктів вдруге.

— tandrewnichols

4

@Abhilash Будь ласка, прийміть відповідь kirikaza. Я (як і tandrewnichols) зробив це, і був набагато простіший спосіб (і Інтернет, здається, погоджувався, оскільки ця відповідь має 4 рази нагороди).

— Девід Дорія

Зараз це 10-кратне оновлення ... також використовуйте git rerere, щоб запам'ятати свої конфліктні рішення (корисно, якщо ви іноді не приймаєте погані рішення, які не хочете, щоб вони запам'ятовували).

— Аякс

216

Просто роби git reset --soft HEAD^. Він переміщує вказівник HEAD до його батьківського, але зберігає дерево роботи та додає зміну об’єднання до індексу. Таким чином, ви можете продовжувати оприлюднення, git rebase --continueяк і раніше.

— kirikaza
джерело

1

Це повністю спрацювало, і вперше я знайшов застосування для --soft. Приємно знати, як це працює, дякую!

— mmocny

1

Я сподіваюся, що люди побачать усі голоси на цю відповідь і дотримуються запропонованих тут!

— Рагу

1

Це саме те, що я думав (але, можливо, пройшло важко випадково). Не був впевнений, чи HEAD оновлювався під час оновлення. Дякую за підтвердження! Тож радий, що я прокрутив трохи далі, перш ніж возитися з головним болем вище.

— DeezCashews

Я відредагував прийняту відповідь, щоб покласти тут посилання - я не бачив цієї відповіді, поки не дотримувався вказівок вище.

— xaxxon

0

У мене виникла та ж проблема, і що ще гірше, я звільнив три коміти, і після вирішення конфліктів на другому комітті я "здійснив" замість "rebase - продовжувати".

Як результат, у мене виник цей рефлог

Коли я застосував рішення kirikaza, я просто відмінив третє, а не друге, що було проблематично ..

Як бачимо, ребаза починається з каси з відділення віддалених / вихідних / головних, а потім застосовує три мої коміти, які відображаються як три попередні операції (перед оформленням замовлення) у рефлогу.

Потім, якщо ви хочете перезапустити з чистої бази, перед початком відновлення, ви можете просто скинути жорсткий хеш безпосередньо перед оформленням операції ребазування. У моєму випадку (див. Малюнок):

git reset --hard 859ed3c

Тоді можна починати нове git rebase.

— Луї Дюран
джерело

0

У мене було відновлено git, виправлені конфлікти, додано файл git із конфліктами та (помилково) здійснено.

Я спробував git reset --soft HEAD^і запропоновані git reset --hardрішення, але жодне не працювало для мене.

Однак якраз git rebase --abortпрацював: це повернуло мене до початку ребазування з чистим робочим деревом.

— залишок
джерело