Подтвердить что ты не робот

Восстановить из git reset --hard?

Есть ли способ восстановить незафиксированные изменения в рабочий каталог из git reset --hard HEAD?

4b9b3361

Ответ 1

Вы не можете вернуть незафиксированные изменения в целом.

Предварительно подготовленные изменения (git add) должны быть восстановлены из индексных объектов, поэтому, если вы это сделали, используйте git fsck --lost-found, чтобы найти связанные с ним объекты. (Это записывает объекты в каталог .git/lost-found/; оттуда вы можете использовать git show <filename>, чтобы увидеть содержимое каждого файла.)

Если нет, ответ здесь будет: посмотрите на свою резервную копию. Возможно, ваш редактор /IDE хранит временные копии в /tmp или C:\TEMP и тому подобное. [1]

git reset [email protected]{1}

Это восстановит предыдущую ГОЛОВУ

[1] vim например опционально сохраняет постоянную отмену, eclipse IDE хранит локальную историю; такие функции могут сохранить ваш **

Ответ 2

ответьте на это fooobar.com/questions/22524/...

$ git reflog show
93567ad [email protected]{0}: reset: moving to [email protected]{6}    
203e84e [email protected]{1}: reset: moving to [email protected]{1}    
9937a76 [email protected]{2}: reset: moving to [email protected]{2}
203e84e [email protected]{3}: checkout: moving from master to master
203e84e [email protected]{4}: reset: moving to HEAD~1
9937a76 [email protected]{5}: reset: moving to HEAD~1
d5bb59f [email protected]{6}: reset: moving to HEAD~1
9300f9d [email protected]{7}: commit: fix-bug

# said the commit to be recovered back is on 9300f9d (with commit message fix-bug)
$ git reset [email protected]{7}

Ты вернешь свой день!:)

Ответ 3

Сегодня я случайно запустил git reset --hard на своем репо, но сегодня тоже получил незафиксированные изменения. Чтобы получить его обратно, я запустил git fsck --lost-found, который записал все не имеющие ссылки большие двоичные объекты в <path to repo>/.git/lost-found/. Поскольку файлы не были переданы, я нашел их в каталоге other внутри <path to repo>/.git/lost-found/. Оттуда я могу видеть незафиксированные файлы, используя git show <filename>, копировать капли и переименовывать их.

Примечание. Это работает только в том случае, если вы добавили в индекс файлы, которые хотите сохранить (используя git add .). Если файлы не были в индексе, они будут потеряны.

Ответ 4

Да, ВЫ МОЖЕТЕ ВОССТАНОВИТЬСЯ из жесткого reset в git.

Использование:

git reflog

чтобы получить идентификатор вашей фиксации. Затем используйте:

git reset --hard <commit-retrieved-using-reflog>

Этот трюк спас мою жизнь пару раз.

Вы можете найти документацию reflog ЗДЕСЬ.

Ответ 5

Пока я работал над локальным проектом, я хотел переместить его в GitHub, а затем создал новый репозиторий. Хотя я пытался добавить все эти файлы в новый репозиторий с помощью .gitignore, я случайно добавил неверный файл, а затем попытался его очистить.

Я запустил git reset --hard origin/master: P

Затем все мои локальные файлы удалены, поскольку репо было пустым. Я думал, что все прошло.

Это спасло мою жизнь:

  git reflog show
git reset HEAD @{1}
git push
Код>

Надеюсь, что это спасет другую жизнь.

Ответ 6

Если вы используете что-то вроде IntelliJ:

В контекстном меню выберите "Локальная история" и нажмите "Показать историю" в подменю:

Представление локальной истории проекта или папки показывает все, что вы сделали за последние несколько дней. В столбце "Действие" в нижней части диалогового окна выберите действие, которое необходимо откатить. [...] Таким образом, в верхней части диалогового окна отображается древовидная структура измененных файлов. Если вы хотите восстановить только удаленный файл, независимо от других изменений, которые были сделаны с тех пор, вы можете выбрать файл Lost.txt в виде дерева и нажать кнопку "Восстановить".

http://blog.jetbrains.com/idea/2008/01/using-local-history-to-restore-deleted-files/

Это только что вытащило мою задницу из огня!

Ответ 7

Я только что сделал git reset --hard и потерял все мои незафиксированные изменения. К счастью, я использую редактор (IntelliJ), и мне удалось восстановить изменения в Local History. Eclipse должен позволить вам сделать то же самое.

Ответ 8

По определению git reset --hard выкинет незафиксированные изменения без возможности для Git восстановить их (ваша резервная система может помочь, но не Git).

На самом деле, очень мало случаев, когда git reset --hard - хорошая идея. В большинстве случаев есть более безопасная команда, чтобы сделать то же самое:

  • Если вы хотите выбросить свои незафиксированные изменения, используйте git stash. Он сохранит резервную копию этих изменений, срок действия которых истекает через некоторое время, если вы запустите git gc. Если вы на 99,9% уверены, что вам никогда не понадобится эти изменения, тогда git stash по-прежнему ваш друг для случая 0,1%. Если вы на 100% уверены, то git stash по-прежнему ваш друг, потому что у этих 100% есть ошибка измерения; -).

  • Если вы хотите переместить HEAD и кончик текущей ветки в историю, то git reset --keep - ваш друг. Он будет делать то же самое, что и git reset --hard, но не отменит ваши локальные изменения.

  • Если вы хотите сделать оба, то git stash && git reset --keep - ваш друг.

Учите свои пальцы не использовать git reset --hard, он окупится в один прекрасный день.

Ответ 9

Это то, что я обычно делаю, если я теряю некоторые изменения.

git reflog
git checkout <commit id> // now you are in where you want but you cannot push from detached branch to master
manually copy and paste changes from detached branch to master or working branch
git reset --hard HEAD // if needed
git add ... > git commit ... > git push ...

чтобы переместить указатель назад к вашим предыдущим коммитам, но сохранить изменения, которые вы сделали до сих пор в вашей последней проверке git reset --soft dadada

Ответ 10

если вы случайно сбросили коммит, то сделайте это,

git reflog show
git reset [email protected]{2} // i.e where HEAD used to be two moves ago - may be different for your case

при условии, что [email protected]{2} - это состояние, в которое вы хотите вернуться

Ответ 11

Информация теряется.

Поскольку вы не совершали, ваш .git никогда не хранил эту информацию. Таким образом, в основном git не может восстановить его для вас.

Но, если вы только что сделали git diff, вы можете восстановить с помощью вывода терминала следующие 3 простых шага.

  • прокрутите свой терминал и найдите o/p git diff. Сохраните файл o/p в файле с именем diff.patch
  • Найдите и замените все 7 пробелов и 8 пробелов символом tab (\ t) и сохраните изменения.
  • Перейдите в репозиторий git. Примените diff.patch(patch -p1 < diff.patch)

Вы спасены!:)

Примечание. Когда вы копируете данные с терминала в файл, будьте осторожны и четко видите, что данные являются непрерывными и не содержат избыточных данных (из-за нажатия стрелок вверх и вниз). В противном случае вы можете испортить его.

Ответ 12

Вы можете вернуть фиксацию после выполнения reset --hard HEAD.

Используйте "git reflog", чтобы проверить историю HEAD в ветке.

Вы увидите свою фиксацию и ее идентификатор.

Сделайте

git reset {commit Id of the commit you want to bring back}

Ответ 13

Я столкнулся с той же проблемой, и я почти сходил с ума.... сначала я зафиксировал проект и объединился... позже, когда я попытался запустить git push --set-upstream origin master я получил эту ошибку

  fatal: refusing to merge unrelated histories

поэтому я запустил git reset --hard HEAD и он удалил 3-недельный проект, но эти несколько команд ниже спасают день:

git reset [email protected]{1}         //this command unstage changes after reset
git fsck --lost-found      //I got the dangling commit fc3b6bee2bca5d8a7e16b6adaca6a76e620eca4b
git show <dangling commit something like-> fc3b6bee2bca5d8a7e16b6adaca6a76e620eca4b>
git rebase fc3b6bee2bca5d8a7e16b6adaca6a76e620eca4b

надеюсь это поможет

Ответ 14

Если вы, к счастью, открыли те же файлы в другом редакторе (например, Sublime Text), попробуйте ctrl-z. Это просто спасло меня.

Ответ 15

Я обнаружил, что все незафиксированные файлы до git reset --hard <commit> удаляются из истории git. Тем не менее, мне посчастливилось сохранить открытый сеанс редактора кода в течение всего времени, когда я вытаскивал свои волосы, что я обнаружил, что простой control + z в каждом из затронутых файлов возвратил состояние файла обратно в версию перед git настолько услужливо reset все, о чем я не спросил его конкретно. Hooray!!

Ответ 16

Если вы пытаетесь использовать код ниже:

git reflog show
# head to recover to
git reset [email protected]{1} 

и по какой-то причине получают:

ошибка: неизвестный переключатель 'e'

затем попробуйте заключить [email protected]{1} в кавычки

git reset '[email protected]{1}'

Ответ 17

Правильные ответы. ОК, теперь я люблю мерзавца :-) Здесь более простой рецепт.

git log [email protected]{2}
git reset --hard  [email protected]{2}

Где "2" - это номер возврата туда, где вы зафиксировали свои изменения. В моем случае его прервали коллеги и боссы, чтобы помочь отладить некоторые проблемы со сборкой; итак, сделал сброс --hard дважды; Итак, HEAD и HEAD @{1} были перезаписаны. Фух, потерял бы наш тяжелый труд.

Ответ 18

Ссылка на этот SO,

После запуска git reflog show скажите, что вы хотите перейти на фиксацию 9300f9d

после запуска git reset 9300f9d

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

git checkout - filepath/name

Ответ 19

Если вы разрабатываете на Netbeans, посмотрите между вкладками файлов и областью редактирования файлов. Есть "Источник" и "История". В "Истории" вы увидите изменения, сделанные с помощью контроля версий (git/other), а также изменения, сделанные локально. В этом случае локальные изменения могут вас спасти.

Ответ 20

(ответ подходит для подмножества пользователей)

Если вы используете (любую последнюю) macOS, и даже если вы находитесь за пределами диска Time Machine, ОС будет сохранять ежечасные резервные копии, называемые локальные снимки.

Введите Time Machine и перейдите к файлу, который вы потеряли. ОС спросит вас:

The location to which you're restoring "file.ext" already contains an
item with the same name. Do you want to replace it with the one you're
restoring?

Вы должны иметь возможность восстановить потерянные файлы.

Ответ 21

Когда мы делаем git reset --hard, и все локальные недействительные изменения удаляются. Чтобы восстановить изменения - в IDE щелкните файл, сравните файл с локальной историей, в которой будут перечислены изменения в соответствии с датой, и мы сможем восстановить данные. Ваш день сохранен!