Как я могу отменить git reset --hard HEAD ~ 1?

Можно ли отменить изменения, вызванные следующей командой? Если да, то как?

git reset --hard HEAD~1

Ответов (18)

Решение

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

$ git init
Initialized empty Git repository in .git/

$ echo "testing reset" > file1
$ git add file1
$ git commit -m 'added file1'
Created initial commit 1a75c1d: added file1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file1

$ echo "added new file" > file2
$ git add file2
$ git commit -m 'added file2'
Created commit f6e5064: added file2
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file2

$ git reset --hard HEAD^
HEAD is now at 1a75c1d... added file1

$ cat file2
cat: file2: No such file or directory

$ git reflog
1a75c1d... [email protected]{0}: reset --hard HEAD^: updating HEAD
f6e5064... [email protected]{1}: commit: added file2

$ git reset --hard f6e5064
HEAD is now at f6e5064... added file2

$ cat file2
added new file

В этом примере вы можете видеть, что файл file2 был удален в результате аппаратного сброса, но был возвращен на место, когда я выполнял сброс через reflog.

Его можно восстановить, если Git еще не собрал мусор.

Получите обзор зависших коммитов с помощью fsck :

$ git fsck --lost-found
dangling commit b72e67a9bb3f1fc1b64528bcce031af4f0d6fcbf

Восстановите болтающуюся фиксацию с помощью rebase:

$ git rebase b72e67a9bb3f1fc1b64528bcce031af4f0d6fcbf

Если вам действительно повезло, как и мне, вы можете вернуться в свой текстовый редактор и нажать «Отменить».

Я знаю, что это не совсем правильный ответ, но он сэкономил мне полдня работы, так что, надеюсь, он сделает то же самое для кого-то другого!

Я знаю, что это старая ветка ... но поскольку многие люди ищут способы отменить что-то в Git, я все же думаю, что было бы неплохо продолжать давать здесь советы.

Когда вы выполняете «git add» или перемещаете что-либо из верхнего левого угла в нижний левый в git gui, содержимое файла сохраняется в большом двоичном объекте, и содержимое файла можно восстановить из этого большого двоичного объекта.

Таким образом, можно восстановить файл, даже если он не был зафиксирован, но должен быть добавлен.

git init  
echo hello >> test.txt  
git add test.txt  

Теперь большой двоичный объект создан, но на него ссылается индекс, поэтому он не будет отображаться с помощью git fsck до тех пор, пока мы не выполним сброс. Итак, сбрасываем ...

git reset --hard  
git fsck  

вы получите свисающую каплю ce013625030ba8dba906f756967f9e9ca394464a

git show ce01362  

вернет вам содержимое файла "привет"

Чтобы найти коммиты без ссылок, я где-то нашел подсказку, предлагающую это.

gitk --all $(git log -g --pretty=format:%h)  

У меня есть это как инструмент в git gui, и он очень удобен.

Сделал крошечный скрипт, чтобы облегчить поиск нужной фиксации:

git fsck --lost-found | grep commit | cut -d ' ' -f 3 | xargs -i git show \{\} | egrep '^commit |Date:'

Да, его можно сделать значительно красивее с помощью awk или чего-то подобного, но он простой, и мне это просто нужно. Может спасти кого-нибудь еще на 30 секунд.

Пример случая IRL:

$ git fsck --lost-found

Checking object directories: 100% (256/256), done.
Checking objects: 100% (3/3), done.
dangling blob 025cab9725ccc00fbd7202da543f556c146cb119
dangling blob 84e9af799c2f5f08fb50874e5be7fb5cb7aa7c1b
dangling blob 85f4d1a289e094012819d9732f017c7805ee85b4
dangling blob 8f654d1cd425da7389d12c17dd2d88d318496d98
dangling blob 9183b84bbd292dcc238ca546dab896e073432933
dangling blob 1448ee51d0ea16f259371b32a557b60f908d15ee
dangling blob 95372cef6148d980ab1d7539ee6fbb44f5e87e22
dangling blob 9b3bf9fb1ee82c6d6d5ec9149e38fe53d4151fbd
dangling blob 2b21002ca449a9e30dbb87e535fbd4e65bac18f7
dangling blob 2fff2f8e4ea6408ac84a8560477aa00583002e66
dangling blob 333e76340b59a944456b4befd0e007c2e23ab37b
dangling blob b87163c8def315d40721e592f15c2192a33816bb
dangling blob c22aafb90358f6bf22577d1ae077ad89d9eea0a7
dangling blob c6ef78dd64c886e9c9895e2fc4556e69e4fbb133
dangling blob 4a71f9ff8262701171d42559a283c751fea6a201
dangling blob 6b762d368f44ddd441e5b8eae6a7b611335b49a2
dangling blob 724d23914b48443b19eada79c3eb1813c3c67fed
dangling blob 749ffc9a412e7584245af5106e78167b9480a27b
dangling commit f6ce1a403399772d4146d306d5763f3f5715cb5a    <- it's this one

$ git show f6ce1a403399772d4146d306d5763f3f5715cb5a

commit f6ce1a403399772d4146d306d5763f3f5715cb5a
Author: Stian Gudmundsen Høiland <[email protected]>
Date:   Wed Aug 15 08:41:30 2012 +0200

    *MY COMMIT MESSAGE IS DISPLAYED HERE*

diff --git a/Some.file b/Some.file
new file mode 100644
index 0000000..15baeba
--- /dev/null
+++ b/Some.file
*THE WHOLE COMMIT IS DISPLAYED HERE*

$ git rebase f6ce1a403399772d4146d306d5763f3f5715cb5a

First, rewinding head to replay your work on top of it...
Fast-forwarded master to f6ce1a403399772d4146d306d5763f3f5715cb5a.

Я только что сделал полный сброс не того проекта. Мне жизнь спасла местная история «Затмения». Говорят, что у IntelliJ Idea тоже есть такая возможность, и пусть ваш редактор тоже, стоит проверить:

  1. Раздел справки Eclipse по локальной истории
  2. http://wiki.eclipse.org/FAQ_Where_is_the_workspace_local_history_stored%3F

В большинстве случаев да.

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

Ниже я перечислил ряд различных возможных сценариев и способы восстановления после них.

Все мои изменения были зафиксированы, но теперь коммитов больше нет!

Эта ситуация обычно возникает, когда вы запускаете git reset аргумент, например git reset --hard HEAD~ . Не волнуйтесь, от этого легко избавиться!

Если вы просто бежали git reset и с тех пор больше ничего не делали, вы можете вернуться туда, где были, с помощью этой однострочной строки:

git reset --hard @{1}

Это сбрасывает вашу текущую ветку в любом состоянии, в котором она была до последнего изменения (в вашем случае самой последней модификацией ветки будет жесткий сброс, который вы пытаетесь отменить).

Однако, если вы уже сделали другие изменения в вашей отрасли с сброса, один вкладыш выше не будет работать. Вместо этого вы должны запустить, чтобы увидеть список всех последних изменений, внесенных в вашу ветку (включая сбросы). Этот список будет выглядеть примерно так:git reflog <branchname>

7c169bd [email protected]{0}: reset: moving to HEAD~
3ae5027 [email protected]{1}: commit: Changed file2
7c169bd [email protected]{2}: commit: Some change
5eb37ca [email protected]{3}: commit (initial): Initial commit

Найдите в этом списке операцию, которую вы хотите «отменить». В приведенном выше примере это будет первая строка, в которой написано «reset: перемещение в HEAD ~». Затем скопируйте представление фиксации перед (ниже) этой операцией. В нашем случае это будет [email protected]{1} (или 3ae5027 они оба представляют одну и ту же фиксацию) и запустить, git reset --hard <commit> чтобы сбросить текущую ветку обратно в эту фиксацию.

Я поставил свои изменения git add, но так и не зафиксировал. Теперь мои изменения пропали!

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

Подробнее об этом см. В разделе Отменить git reset --hard с незафиксированными файлами в промежуточной области .

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

Ой ой. Ненавижу говорить тебе это, но тебе, вероятно, не повезло. git не сохраняет изменения, которые вы не добавляете и не фиксируете, и согласно документации дляgit reset :

--жесткий

Сбрасывает индекс и рабочее дерево. Любые изменения в отслеживаемых файлах в рабочем дереве с тех пор <commit>отменяются.

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

Насколько я знаю, --hard незафиксированные изменения будут отброшены. Поскольку они не отслеживаются git. но вы можете отменить discarded commit .

$ git reflog

будет перечислять:

b0d059c [email protected]{0}: reset: moving to HEAD~1
4bac331 [email protected]{1}: commit: added level introduction....
....

где 4bac331 находится discarded commit .

Теперь просто переместите голову к этому коммиту:

$ git reset --hard 4bac331

Если вы используете IDE JetBrains (что-либо на основе IntelliJ), вы можете восстановить даже свои незавершенные изменения с помощью их функции «Локальная история».

Щелкните правой кнопкой мыши каталог верхнего уровня в дереве файлов, найдите «Локальная история» в контекстном меню и выберите «Показать историю». Это откроет представление, в котором можно найти ваши недавние правки, и как только вы найдете ревизию, к которой хотите вернуться, щелкните ее правой кнопкой мыши и выберите «Вернуть».

Это спасло мне жизнь: https://medium.com/@CarrieGuss/how-to-recover-from-a-git-hard-reset-b830b5e3f60c

В основном вам нужно запустить:

for blob in $(git fsck --lost-found | awk ‘$2 == “blob” { print $3 }’); do git cat-file -p $blob > $blob.txt; done

Затем вручную пытайтесь реорганизовать ваши файлы в правильную структуру.

Вывод: никогда не используйте, git reset --hard если вы не на 100% понимаете, как это работает, лучше не использовать.

git reflog и вернуться к последней HEAD 6a56624 (HEAD -> master) HEAD @ {0}: reset: перейти к HEAD ~ 3 1a9bf73 HEAD @ {1}: commit: добавить изменения в модель сгенерировать двоичный файл

Прежде чем ответить, давайте добавим немного предыстории, объясняя, что это такое HEAD .

First of all what is HEAD?

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

Содержимое HEAD хранится внутри .git/HEAD и содержит 40 байт SHA-1 текущего коммита.


detached HEAD

Если вы не в последней фиксации - это означает, что HEAD это указывает на предыдущую фиксацию в истории, которую он вызывал detached HEAD.

введите описание изображения здесь

В командной строке это будет выглядеть так: SHA-1 вместо имени ветки, так как HEAD не указывает на конец текущей ветки.

введите описание изображения здесь


Несколько вариантов восстановления после отсоединенной HEAD:


git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

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

# Checkout a given commit. 
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

Вы всегда можете использовать reflog также.
git reflog отобразит любое изменение, которое обновило HEAD файл, и проверка нужной записи в журнале рефлога HEAD вернет этот коммит.

Каждый раз, когда HEAD изменяется, в reflog

git reflog
git checkout [email protected]{...}

Это вернет вас к желаемой фиксации

введите описание изображения здесь


git reset HEAD --hard <commit_id>

«Переместите» голову обратно к желаемой фиксации.

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to.
  • Примечание. ( Начиная с Git 2.7 )
    вы также можете использовать git rebase --no-autostash.


git revert <sha-1>

«Отменить» данную фиксацию или диапазон фиксации.
Команда сброса «отменит» любые изменения, сделанные в данной фиксации.
Новая фиксация с патчем отмены будет зафиксирована, в то время как исходная фиксация также останется в истории.

# add new commit with the undo of the original one.
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>

Эта схема показывает, какая команда что делает.
Как видите, reset && checkout измените файл HEAD .

введите описание изображения здесь

git reflog

  • Найдите свой коммит sha в списке, затем скопируйте и вставьте его в эту команду:

git cherry-pick <the sha>

Что вы хотите сделать, так это указать sha1 фиксации, в которую вы хотите восстановить. Вы можете получить sha1, проверив reflog ( git reflog ), а затем выполнив

git reset --hard <sha1 of desired commit>

Но не ждите слишком долго ... через несколько недель git в конечном итоге увидит, что этот коммит не имеет ссылки, и удалит все капли.

Если вы еще не собрали мусор в своем репозитории (например, с помощью git repack -d или git gc, но обратите внимание, что сборка мусора также может происходить автоматически), то ваша фиксация все еще существует - она ​​просто больше не доступна через HEAD.

Вы можете попытаться найти свою фиксацию, просмотрев вывод git fsck --lost-found .

В новых версиях Git есть так называемый «журнал ссылок», который представляет собой журнал всех изменений, внесенных в ссылки (в отличие от изменений, внесенных в содержимое репозитория). Так, например, каждый раз, когда вы переключаете свой HEAD (то есть каждый раз, когда вы выполняете a git checkout для переключения ветвей), это будет регистрироваться. И, конечно же, вы git reset также манипулировали HEAD, поэтому он также был зарегистрирован. Вы можете получить доступ к более старым состояниям ваших ссылок аналогично тому, как вы можете получить доступ к более старым состояниям вашего репозитория, используя @ знак вместо ~, например git reset [email protected]{1} .

Мне потребовалось время, чтобы понять, в чем разница между HEAD @ {1} и HEAD ~ 1, поэтому вот небольшое объяснение:

git init
git commit --allow-empty -mOne
git commit --allow-empty -mTwo
git checkout -b anotherbranch
git commit --allow-empty -mThree
git checkout master # This changes the HEAD, but not the repository contents
git show HEAD~1 # => One
git show [email protected]{1} # => Three
git reflog

Таким образом, это HEAD~1 означает «перейти к фиксации перед фиксацией, на которую в данный момент указывает HEAD», а [email protected]{1} означает «перейти к фиксации, на которую указывал HEAD до того, как она указала на то место, на которое он указывает в данный момент».

Это легко позволит вам найти потерянный коммит и восстановить его.

Ответ скрыт в подробном ответе выше, вы можете просто сделать:

$> git reset --hard [email protected]{1}

(См. Вывод git reflog show )

Моя проблема почти аналогична. Перед входом у меня есть незафиксированные файлы git reset --hard .

К счастью. Мне удалось пропустить все эти ресурсы. После того, как я заметил, что могу просто отменить ( ctrl-z ). Я просто хочу добавить это ко всем приведенным выше ответам.

Примечание. Невозможно для ctrl-zнеоткрытых файлов.