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

Я пытаюсь восстановить свою работу. Я тупо делал git reset --hard, а до этого только делал get add .и не делал git commit. Пожалуйста помоги! Вот мой журнал:

MacBookPro:api user$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)

#   modified:   .gitignore
...


MacBookPro:api user$ git reset --hard
HEAD is now at ff546fa added new strucuture for api

Возможна ли отмена git reset --hardв этой ситуации?

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

• Восстановление добавленного файла после выполнения git reset --hard HEAD ^

Однако я попробовал это в тестовом репозитории, и возникла пара проблем - --cachedдолжно быть --cache, и я обнаружил, что на самом деле .git/lost-foundкаталог не создавался . Однако у меня сработали следующие шаги:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)")

Это должно вывести все объекты в базе данных объектов, которые недоступны ни по какой ссылке, в индексе или через журнал ссылок. Результат будет выглядеть примерно так:

unreachable blob 907b308167f0880fb2a5c0e1614bb0c7620f9dc3
unreachable blob 72663d3adcf67548b9e0f0b2eeef62bce3d53e03

... и для каждой из этих капель вы можете:

git show 907b308

Чтобы вывести содержимое файла.

Слишком много вывода?

Обновление в ответ на sehe «s комментарий ниже:

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

Сначала сохраните вывод команды с помощью:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)") > all

Теперь имена объектов этих недостижимых коммитов можно найти с помощью:

egrep commit all | cut -d ' ' -f 3

Таким образом, вы можете найти только деревья и объекты, которые были добавлены в индекс, но не зафиксированы в какой-либо момент, с помощью:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)") \
  $(egrep commit all | cut -d ' ' -f 3)

Это значительно сокращает количество объектов, которые вам нужно учитывать.

Обновление: Филип Окли ниже предлагает другой способ сократить количество объектов для рассмотрения, а именно рассматривать файлы, которые были недавно изменены .git/objects. Вы можете найти их с помощью:

find .git/objects/ -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort

(Я нашел этот findвызов здесь .) Конец этого списка может выглядеть так:

2011-08-22 11:43:43.0234896770 .git/objects/b2/1700b09c0bc0fc848f67dd751a9e4ea5b4133b
2011-09-13 07:36:37.5868133260 .git/objects/de/629830603289ef159268f443da79968360913a

В этом случае вы можете увидеть эти объекты с помощью:

git show b21700b09c0bc0fc848f67dd751a9e4ea5b4133b
git show de629830603289ef159268f443da79968360913a

(Обратите внимание, что вам нужно удалить /символ в конце пути, чтобы получить имя объекта.)

Я только что сделал git reset --hardи потерял одну фиксацию. Но я знал хеш фиксации, поэтому смог git cherry-pick COMMIT_HASHвосстановить его.

Я сделал это в течение нескольких минут после потери фиксации, поэтому для некоторых из вас это может сработать.

Благодаря Марку Лонгару я вернул свои вещи!

Сначала я сохранил все хэши в файл:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)") > allhashes

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

commits = ["c2520e04839c05505ef17f985a49ffd42809f",
    "41901be74651829d97f29934f190055ae4e93",
    "50f078c937f07b508a1a73d3566a822927a57",
    "51077d43a3ed6333c8a3616412c9b3b0fb6d4",
    "56e290dc0aaa20e64702357b340d397213cb",
    "5b731d988cfb24500842ec5df84d3e1950c87",
    "9c438e09cf759bf84e109a2f0c18520",
    ...
    ]

from subprocess import call
filename = "file"
i = 1
for c in commits:
    f = open(filename + str(i),"wb")
    call(["git", "show", c],stdout=f)
    i+=1

Решение @Ajedi32 в комментариях сработало для меня именно в этой ситуации.

git reset --hard @{1}

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

Решили ту же проблему, но не добавили изменений в индекс. Таким образом, все приведенные выше команды не вернули мне желаемых изменений.

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

В отчаянии я попытался нажать CTRL-Z в своем редакторе (LightTable) один раз на каждой открытой вкладке - это, к счастью, восстановило файл на этой вкладке до его последнего состояния до git reset --hard. НТН.

Это, вероятно, очевидно для профессионалов в области git, но я хотел рассказать об этом, так как в моих безумных поисках я не заметил, чтобы это поднялось.

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

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

Опять же, для большинства в этом, вероятно, нет ничего нового, но я надеюсь, что, поскольку это помогло мне, и я не нашел ничего, предполагающего это, это может помочь кому-то другому.

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

1. Как упоминалось chilicuil, запустите, git reflogчтобы определить там хеш фиксации, к которому вы хотите вернуться.

2. Как упомянул akimsko, вы, скорее всего, НЕ захотите выбирать вишню, если только не потеряли только одну фиксацию, поэтому вам следует запустить git reset --hard <hash-commit-you-want>

Примечание для пользователей egit Eclipse: я не смог найти способ выполнить эти шаги в Eclipse с помощью egit. Закрытие Eclipse, выполнение приведенных выше команд из окна терминала, а затем повторное открытие Eclipse сработали для меня отлично.

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

Вот шаги:

1. В vim нажмите :и введите команду set undodir. Если вы persistent undoвключили в своем .vimrc, он покажет результат, подобный undodir=~/.vim_runtime/temp_dirs/undodir.

2. В вашем репо используйте, git logчтобы узнать последнюю дату / время, когда вы сделали последнюю фиксацию

3. В вашей оболочке перейдите к своему undodirusing cd ~/.vim_runtime/temp_dirs/undodir.

4. В этом каталоге используйте эту команду, чтобы найти все файлы, которые вы изменили с момента последней фиксации.

   find . -newermt "2018-03-20 11:24:44" \! -newermt "2018-03-23" \( -type f -regextype posix-extended -regex '.*' \) \-not -path "*/env/*" -not -path "*/.git/*"

   Здесь «2018-03-20 11:24:44» - это дата и время последней фиксации. Если вы сделали дату git reset --hard«2018-03-22», используйте «2018-03-22», затем используйте «2018-03-23». Это из-за причуды find, где нижняя граница является включительной, а верхняя граница является исключительной. https://unix.stackexchange.com/a/70404/242983

5. Затем перейдите к каждому из файлов, откройте их в vim и выполните «20 минут раньше». Вы можете найти более подробную информацию о «ранее», используя «h ранее». Здесь earlier 20mимеется в виду возврат к состоянию файла на 20 минут назад, при условии, что вы сделали это git hard --reset20 минут назад. Повторите это для всех файлов, которые были выведены из findкоманды. Я уверен, что кто-нибудь сможет написать сценарий, который объединит эти вещи.

Я использую IntelliJ и могу просто просмотреть каждый файл и сделать:

Edit -> reload from disk

К счастью, git statusперед тем, как стереть свои рабочие изменения, я сделал все правильно, поэтому я точно знал, что мне нужно перезагрузить.

Запоминание иерархии файлов и использование техники Марка Лонгаира с модификацией Фила Окли дает потрясающие результаты.

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

НТН!

Если вы недавно просмотрели a, git diffто есть другой способ восстановиться после подобных инцидентов, даже если вы еще не внесли изменения: если вывод git diffвсе еще находится в буфере вашей консоли, вы можете просто прокрутить вверх, скопировать и вставить дифф в файл и использовать patchинструмент , чтобы применить диф в дерево: patch -p0 < file. Такой подход меня несколько раз спасал.