Git корумпована головна галузь


9

Я відкриваю своє сховище Git за допомогою gitExtensions в Windows 7 для проекту Visual Studio. Він раптом порожній. Сховище існує, але всі мої комісії зникли.

Я використовую графічний інтерфейс, і я вважаю, що це вперше я відкрив його з моменту оновлення.

Я не впевнений, що робити щодо повернення своїх зобов'язань.

Коли я набираю

git log 

я отримую

фатально: погана версія за замовчуванням "HEAD"

Оновлення
Після перегляду /programming/1545407/recovering-broken-git-repository я спробував

git fsck

він повернувся:

помилка: Недійсний HEAD
фатальний: пухкий об'єкт 36b7d9e1ca496bcb864c0b9c8671fcec97fbda31 (зберігається у .git / obj ects / 36 / b7d9e1ca496bcb864c0b9c8671fcec97fbda31) пошкоджений

Здійснення повернення:

помилка: не вдається вирішити посилання HEAD: Немає такого файлу чи каталогу
фатально: неможливо заблокувати HEAD ref

і повернення головного відділення відділення

$ git журнал головного попередження: ігнорування пошкоджених ref refs / heads / master. попередження: ігнорування пошкоджених реф. кодів / голів / майстер. fatal: неоднозначний аргумент 'master': невідома редакція або шлях не в робочому дереві. Використовуйте "-", щоб відокремити шляхи від версій

Я просто продовжую вставляти речі, які можуть бути актуальними

$ git reflog головне
попередження: ігнорування пошкоджених ref refs / heads / master.
попередження: ігнорування пошкоджених реф. кодів / голів / майстер.
fatal: неоднозначний аргумент 'master': невідома редакція або шлях не в робочому дереві.
Використовуйте "-", щоб відокремити шляхи від версій

Більш можливо корисна інформація: кожного разу, коли я видаляю пошкоджений файл, інший займає його місце. Я починаю думати, що це щось пов'язане з головним відділенням, що вказує на неправильну річ чи щось. тому що я припускаю, що голова вказує на господаря.

Одного разу пізніше:
тож я зав'язав свого напарника, він зміг пройти журнали, і він сказав, що хеші в журналах не відповідають об'єктам у папці. Він спробував скинути головну гілку до журналів чи щось подібне, я трохи загубився. Сподіваюся, що це корисно



1
@heavyd, будь ласка, перевірте оновлення
MrJD

Відповіді:


3

Сховище існує, але всі мої комісії зникли.

Що саме ти маєш на увазі? Чи працює ще дерево? Чи .git/існує? Чи є в ньому файли?

Опубліковані вами повідомлення свідчать про те, що файл .git/HEADне існує. Він визначає очікуваний стан робочого дерева (що ви перевірили). Якщо цього файлу немає, git не знає, де ви були.

Ви можете спробувати створити файл самостійно за допомогою цього вмісту: ref: refs/heads/master

Якщо ви були на іншій гілці, просто замініть "майстер" на ім'я гілки. Якби ви не були на гілці, було б складніше.

.git/logs/HEADзаписує минулі стани HEAD, з пізнішими рядками внизу. Цей приклад показує замовлення: 25f2a6099fb5f9f2192a510c42f704f9fc4bcecb 65abb1a3dc102e2498860f01fb179cda4c51decb Rainer Blome <rainer.blome@wherever.you.are.com> 1346938344 +0200 checkout: moving from master to MySuperBranch

SHA1 в передній частині посилається на коміти. Ви повинні, наприклад, знаходити їх у журналі філій .git/logs/refs/heads/master.

Вигляд, який ви видали, git reflog, схоже, refs/heads/masterтакож відсутній. Його єдиним змістом повинен бути SHA1 останнього комітету щодо нього (і нового рядка). Наприклад, ви можете знайти останню SHA1 в кінці журналу відділення .git/logs/refs/heads/master.


2

Якщо .git / HEAD існує і його вміст ref: refs/heads/masterперевіряється, то файл refs / heads / master він повинен містити sha1 останнього коміта.

Якщо цей файл був пошкоджений і повний NULL символів Відредагуйте цей файл і поставте sha1 останнього комітету від .git/logs/HEADабо одного до останнього виконання.

Тоді робіть git reset --hard 'sha1 of the commit that you selected'


вона справді була повна NULL знаків, тому я помістив шалі попереднього комітету sha1, але потім скидання git призвело до "помилки: update_ref не вдалося для ref" HEAD ": не вдається заблокувати ref" HEAD ": не вдається вирішити посилання HEAD: Недійсний аргумент "
фантастичний

1

Здається, ваше репо було зіпсоване. Найпростіше зробити це відновити репо-копію із резервної копії або повторно клонувати репо з першоджерела (якщо припустити, що у вас не було тонни роботи).

Якщо перезолотування / клонування не є варіантом, я б рекомендував ознайомитися з програмою Pro Git (безкоштовна онлайн-книга або паперова версія ). Вся книга дуже інформативна, але особливо погляньте на останню главу, щоб зрозуміти, як Git працює всередині. Як тільки ви зрозумієте, як працює Git, подивіться інструкції Лінуса щодо відновлення пошкоджених об'єктів .


Отже, на жаль, я не створив резервну копію прихованих файлів, .git був прихований. У мене насправді не вистачає часу, щоб прочитати цілу книгу, чи є, що ви думаєте, я міг би спробувати?
MrJD

"Прочитати книгу про внутрішні" може бути здоровою загальною порадою, але це не допомагає вирішити конкретну проблему та питання.
Бурхан Алі

0

По деякому часі переглядаючи Інтернет, я нарешті знайшов це, і воно спрацювало.

git fetch origin
git reset --hard origin/master

Це отримує будь-які зміни від origin(сподіваємось, не надто багато роботи, виконаної на місцевому рівні), а потім змушує місцеву masterгілку погодитися з віддаленим. Обережно, --resetозначає відмовитися від будь-яких локальних змін! Крім того, якби вона не була надто зламана, просто git reset origin/masterвідновив би останній відомий (зареєстрований) стан masterфілії.
vonbrand
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.