Одним из недостатков rebase является то, что при неумелом разрешении конфликтов (особенно в бинарных файлах), можно потерять нужную версию файла. Ещё один хороший способ потерять коммит, это удалить ветку, в которой он находится.
Do not panic!
В случае git, “потерять” — это не совсем верное слово. Git хранит последние коммиты, которые больше не находятся в истории, но ещё могут быть туда возвращены.
И так, предположим, мы сделали что-то не так и “потеряли” файл или целый коммит.
Git reflog
Для начала выводим список всех совершённых коммитов (включая те, что уже не являются частью истории какой-либо из существующих веток, и те, что Git делал в тайне от нас)
|
1 |
git reflog |
Теперь нам нужно выбрать коммит, в котором содержатся нужные данные. Тот коммит, который буду восстанавливать я, выделен на скриншоте.
Решаем, что мы хотим сделать: восстановить только какой-либо файл или восстановить весь коммит.
Не забудьте переключиться на ту ветку, в которую вы хотите восстановить данные.
Восстановление файла
Можно восстановить файл как по хешу так и по номеру в стеке reflog. Можно восстановить несколько файлов, для этого нужно записать их через пробел. Перенесённые файлы заменят соответствующие файлы в рабочей копии, и если вы уже успели сделать в них изменения, но ещё не успели зафиксировать, то эти изменения будут потеряны.
|
1 |
git checkout HEAD@{1} ./myfile.cpp |
Или так
|
1 |
git checkout e641ea9 ./myfile.cpp |
Восстановление коммита
Создадим копию нужного коммита и добавим в рабочую ветку.
|
1 |
git cherry-pick HEAD@{1} |
Или так
|
1 |
git cherry-pick e641ea9 |
И так, сегодня мы научились ещё одной “магической” команде, которая может спасти часы нашей работы и сберечь наши нервы.
Leave a Reply
You must be logged in to post a comment.