Как исправить поврежденный репозиторий git?

Ответ 1

В качестве альтернативы последней опции CodeGnome, если повреждено только локальное репо, и вы знаете URL-адрес удаленного, вы можете использовать это, чтобы повторно установить свой .git в соответствии с удаленным (заменив ${url} на удаленный URL-адрес):

  mv -v.git.git_old && & & # удалить старый git
git init && # инициализировать новый репо
git remote add origin "$ {url}" && & # ссылка на старый репо
git fetch && # получить старую историю
git reset origin/master --mixed # принудительное обновление старой истории
Код>

Это оставляет ваше рабочее дерево неповрежденным и влияет только на бухгалтерский учет git.
Я также недавно сделал bash script для этой цели  (Приложение A), что немного снижает безопасность этой операции.

Примечание:

Если у вашего репо есть подмодули, этот процесс каким-то образом их испортит, и единственное решение, которое я нашел до сих пор, - это удалить их, а затем с помощью обновления кода git subodule --init клонирование репо, но это тоже выглядит как ).

Приложение A - Полный сценарий

Ответ 2

TL; DR

Git на самом деле не хранит историю так, как вы думаете. Он вычисляет историю во время выполнения на основе цепи предков. Если в вашей родословной отсутствуют капли, деревья или коммиты, вы не сможете полностью восстановить свою историю.

Восстановление отсутствующих объектов из резервных копий

Первое, что вы можете попробовать, - восстановить отсутствующие элементы из резервной копии. Например, посмотрите, есть ли резервная копия фиксации, сохраненная как .git/objects/98/4c11abfc9c2839b386f29c574d9e03383fa589. Если это возможно, вы можете восстановить его.

Вы также можете посмотреть git-verify-pack и git-unpack-objects в том случае, если commit уже упакован, и вы хотите вернуть его в свободный объект для операций с хранилищем.

Хирургическая резекция

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

• Скопируйте рабочий каталог Git во временный каталог где-нибудь.
• Сделайте жесткий reset неповрежденным фиксатором.
• Скопируйте ваши текущие файлы обратно в дерево работы Git, но не забудьте скопировать папку .git обратно!
• Зафиксируйте текущее дерево работы и сделайте все возможное, чтобы рассматривать его как сжатую фиксацию всей отсутствующей истории.

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

Полное восстановление и повторная инициализация

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

rm -rf .git
git init
git add .
git commit -m 'Re-initialize repository without old history.'

Это сильно, но это может быть ваш единственный вариант, если ваша история репозитория действительно невосстанавливается. YMMV.

Ответ 3

Здесь script (bash) для автоматизации первого решения с помощью @CodeGnome для восстановления из резервной копии (выполняется с верхнего уровня поврежденного репо). Резервное копирование не должно быть полным, оно должно иметь недостающие объекты.

git fsck 2>&1 | grep -e missing -e invalid | awk '{print $NF}' | sort -u |
    while read entry; do
        mkdir -p .git/objects/${entry:0:2}
        cp ${BACKUP}/objects/${entry:0:2}/${entry:2} .git/objects/${entry:0:2}/${entry:2}
    done

Ответ 4

Если у вас настроен удаленный доступ, и вы/не заботитесь о потере какого-либо непроверенного кода, вы можете сделать:

git fetch && git reset --hard

Ответ 5

Если вы в отчаянии, вы можете попробовать следующее:

git clone ssh://[email protected]/path/to/project destination --depth=1

Он получит ваши данные, но вы потеряете историю. Я пошел с проб и ошибок в моем репо и --depth=10 работал, но --depth=50 дал мне сбой.

Ответ 6

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

Другая альтернатива, которая работала для меня, заключалась в reset головке и индексе git в предыдущем состоянии, используя:

git reset --keep

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

Я также пробовал следующие команды, но они не работали для меня, но они могут для вас в зависимости от конкретной проблемы:

git reset --mixed
git fsck --full
git gc --auto
git prune --expire now
git reflog --all

Наконец, чтобы избежать этой проблемы синхронизации, повреждающей ваш индекс git (который может произойти с DropBox, SpiderOak или любым другим облачным диском), вы можете сделать следующее:

• Преобразуйте свою папку .git в один "пакет" git файл, используя: git bundle create my_repo.git --all, тогда он должен работать так же, как и раньше, но поскольку все находится в одном файл, вы не будете подвергать риску синхронизацию, повреждающую ваш репозиторий git.
• Отключить мгновенную синхронизацию. SpiderOak позволяет вам настроить планирование для проверки изменений на "автоматический" (что означает, что это как можно скорее, отслеживание изменений файла благодаря уведомлениям ОС). Это плохо, потому что он начнет загружать изменения, как только вы делаете изменения, а затем загрузите изменения, чтобы они могли удалить последние изменения, которые вы только что делали. Решение этой проблемы заключается в том, чтобы установить задержку мониторинга изменений на 5 минут и более. Это также устраняет проблемы с приложениями для заметок с мгновенным сохранением (например, Notepad ++).

Ответ 7

Я столкнулся с той же проблемой, поэтому я заменил папку ".git" резервной копией, и она все еще не работала, потому что файл .gitconfig был поврежден. BSOD на моем ноутбуке испортил его. Я заменил его следующим кодом, и sourcetree восстановил все мои репозитории.

[user]
name = *your username*
email = *your email address*
[core]
autocrlf = true
excludesfile = C:\\Users\\*user name*\\Documents\\gitignore_global.txt

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

Ответ 8

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

Ответ 9

Я попытался удалить объектные файлы с 0 байтами и извлечь их снова с пульта, и это сработало:

find . -type f -size 0 -exec mv {} /tmp \;
git fetch

Он извлек недостающие объекты с пульта и позволил мне продолжить работу без повторной инициализации всего репо.

Ответ 10

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

Ответ 11

Я хотел добавить это в качестве комментария под Zoey Hewil, отличный ответ выше, но у меня в настоящее время нет достаточно представителей, чтобы сделать это, поэтому я должен добавить это здесь и отдать должное ее работе: P

Если вы используете Poshgit и чувствуете себя чрезвычайно ленивым, вы можете использовать следующее, чтобы автоматически извлечь ваш URL из вашей конфигурации git и упростить работу. Стандартные предостережения относятся к проверке этого на копии/резервное копирование вашего локального репо в случае, если он взорвется вам в лицо.

$config = get-content .git\config
$url = $config -match " url = (?<content>.*)"
$url = $url.trim().Substring(6)
$url

move-item -v .git .git_old;
git init;
git remote add origin "$url";
git fetch;
git reset origin/master --mixed

Ответ 12

Вы можете попробовать на клонированном репо на вашей новой машине, как в Git - как восстановить из пропавшего blob:

git reflog --all --expire=now
git gc --prune=<date> 

Попробуйте "now" для <date>, затем вернитесь во времени, 7 августа, чтобы удалить ссылки на те отсутствующие blobs.
Но это означало бы потерю работы, связанной с этими коммитами...

Для синхронизированной папки (Ubuntu One), только сохранить пакет, а не полное репо.
Пакет - это всего лишь один файл.

Ответ 13

Эта команда работала для меня:

$ git reset --mixed