Git потерял коммиты, которые невозможно найти в истории

Question

У нас есть несколько разработчиков, работающих над общим репозиторием git (они настаивают на этом).

Мы обнаружили, что некоторые коммиты, сделанные разработчиком, потеряны.

Мы можем видеть этиИстория коммитов с помощью команды gitk (используется в Windows).

Но когда мы идем, файл, указанный в коммите, показывается в gitk и видим историю, используя git log filepath, мы не видим этот коммит ввсе.

Мы не знаем, как это может произойти, и не знаем, как восстановиться.

Мы думаем, что таким образом будет потеряно более 10 коммитов от разных разработчиков.

Одна из странностей заключается в том, что мы проверили некоторые старые коммиты, используя git checkout 034534fd, и сделали git cherry-pick 234234321 один за другим.При этом мы получили потерянные коммиты, но ничего не отображается в журнале коммитов '234234321' о поврежденных файлах.

Answer 1

Я немного смущен вашим вопросом. Вы говорите, что вы можете видеть коммиты в gitk, но не в git log -- filepath?

Если это так, ваши коммиты не теряются; Упрощение истории git log скрывает их от вас, потому что они думают, что они неинтересны. Если вы передадите аргумент --full-history на git log, вы должны их увидеть.

Объяснение

По умолчанию, когда вы делаете git log -- filepath, Git не будет показывать вам изменения в этом файле, если Git считает, что это изменение неинтересно. Это называется «упрощением истории». Это часто случается с вишневыми кирками.

Документация по упрощению истории (см. git help log) написана не очень хорошо (очень трудно понять), но вот ключевые части:

Режим по умолчанию

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

[...]

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

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

Аргумент --full-history говорит git log обойти всех родителей, показывая тем самым каждый коммит, который изменил filepath независимо от того, считает ли Git это интересным или нет.

Answer 2

Это могло произойти либо путем фиксации в отдельном HEAD, либо путем удаления ветки, в которой были зафиксированы коммиты.

Если вы видите потерянные коммиты в reflog или rev-list, то самым простым являетсясоздайте ветку с подсказкой о последнем коммите:

git branch recovered <most-recent-SHA1>

Важно предоставить SHA1 самого последнего коммита, который вы хотите получить, иначе его не будет отображаться.

Теперь коммиты находятся в ветке с именем recovered, поэтому вы можете видеть их в своем журнале.Скорее всего, вы захотите объединить или перебазировать ветку recovered.

Answer 3

проверить, появляется ли потерянный коммит в выводе git reflog .

Answer 4

Пока вы не запустили сборку мусора в своем локальном репозитории и у вас есть git reflog, будет работать новая ветка, основанная на самом последнем SHA-1.Если нет, то существуют расширения для корпоративных Git-серверов, такие как Gerrit, которые будут делать то же, что и версия вашей ветки истории.Если ветвь удаляется или обновляется не ускоренным способом (push -f), она будет поддерживать предыдущую версию со специальной ссылкой, чтобы они могли быть восстановлены при необходимости и не были удалены из сборки мусора.Администраторы Gerrit могут по-прежнему удалять выбранные коммиты, если это необходимо по юридическим причинам.