Git Случайно восстановленный первоначальный коммит и удаленный проект

Question

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

Я выполнил некоторые команды из ответов, и когда я запускаю git log --oneline. Единственный коммит ha sh, который появляется, это 287e9ccb (HEAD, master) initial commit, который является моим пустым каталогом, за исключением папки node_modules. Очевидно, я выполнил команду, которая, как я думал, вернется к первому коммиту и потенциально испортила его.

Однако я увидел дополнительную команду для запуска git log --diff-filter=D --summary, в которой перечислены все файлы, которые были удалены. Как я могу сохранить эти удаленные файлы, как они были в «первоначальном коммите»?

Редактировать: работает git reflog, я получаю:

287e9ccb (HEAD, master) master@{0}: reset: moving to 287e9ccb
25a289ec master@{1}: revert: Revert "initial commit" 
287e9ccb (HEAD, master) master@{2}: commit (initial): initial commit

Answer 1

Reflog показывает, что в вашем хранилище всего две коммиты:

• 287e9ccb, что является вашей первоначальной фиксацией
• 25a289ec, что, вероятно, является результатом выполняется git revert 287e9ccb

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

Если второй коммит возврат первого (как следует из его сообщения журнала), он содержит результат отмены первого коммита: то есть удаления всех файлов. Таким образом, второй коммит имеет пустое дерево исходников.

Единственное, что Git хранит навсегда / навсегда ¹ , - это сами коммиты. файлы , с которыми вы работаете, которые вы можете просматривать и редактировать, временные . Извлечение коммита заменяет эти файлы, удаляя эти файлы ² и вставляя их в выбранный вами коммит.

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

---

¹ Даже сами коммиты только так долго, как они могут быть найдены по ha sh ID. Обычно вы (или Git) начинаете с названия ветви или тега, чтобы получить один конкретный идентификатор ha sh. Это позволяет вам найти этот коммит. Затем этот коммит содержит ha sh ID его предыдущего или parent , который позволяет Git найти родительский коммит. Родитель содержит идентификатор ha sh другого более раннего коммита и т. Д.: Он возвращается к самому первому коммиту, который, будучи первым, не записывает более ранний коммит, а затем Git останавливается.

Другими словами, Git работает в обратном направлении. Вы находите ha sh ID last commit из имени ветви, и затем Git работает в обратном направлении. git reset позволяет вам перемещать имена веток в любой коммит с sh ID. Оттуда вы можете только смотреть назад.

reflog содержит все идентификаторы ha sh, которые имя имело в прошлом, в любом случае, до некоторой степени. (Срок действия записей журналов в конце концов истекает, так что журналы не становятся бесконечно длинными.) Поэтому, если вы сбрасываете коммит и не можете его найти, ha sh ID более позднего коммита, который использовало имя , использованное найти будет в вашем журнале.

К сожалению, git reset --hard означает , пожалуйста, уничтожьте мои временные копии файлов, которые есть в индексе и в моем рабочем дереве . Если вы не зафиксировали их, вы не сможете вернуть их обратно.

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