Kho lưu trữ Git bị hỏng sau khi máy tính chết


94

Máy tính của tôi đã chết và bây giờ một trong các kho lưu trữ git của tôi bị hỏng. Khi tôi cố gắng thanh toán, nó cho tôi biết:

warning: ignoring broken ref refs/heads/master.
error: Your local changes to the following files would be overwritten by checkout:
        com.vainolo.jdraw2d.releng.p2/pom.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

Khi tôi thực hiện, git stashtôi nhận được:

fatal: bad revision 'HEAD'
fatal: bad revision 'HEAD'
fatal: Needed a single revision
You do not have the initial commit yet

Vậy tôi có thể làm gì?

Cập nhật đầu ra của git reflog:

fatal: bad default revision 'HEAD'

Không hứa hẹn lắm ... Đầu ra của git fsck:

error: Invalid HEAD
Checking object directories: 100% (256/256), done.
error: unable to unpack 59551f96b4e87a1c14293c19eb548ce6fa1f196f header
error: inflateEnd: stream consistency error (no message)
fatal: loose object 59551f96b4e87a1c14293c19eb548ce6fa1f196f (stored in .git/objects/59/551f96b4e87a1c14293c19eb548ce6fa1f196f) is corrupt

Bạn có thể kiểm tra xem có .git/refs/heads/mastertồn tại hay không và nội dung của nó có phải là một băm cam kết hợp lệ của kho lưu trữ của bạn không (bạn có thể kiểm tra ví dụ như sử dụng git show <hash>)?
poke

Tôi biết điều này là hiển nhiên, nhưng vẫn hỏi - bạn có bất kỳ repo từ xa nào của cùng một repo git không?
Tuxdude

@poke nội dung của .git/refs/heads/master/là một loạt^@
vainolo

@Tuxdude yep, nhưng không được cập nhật những thay đổi mới nhất của tôi
vainolo

1
Điều gì git reflogcho bạn biết? Bạn đã thử chạy git fsckchưa?
kynan

Câu trả lời:


173

Tôi đã khôi phục được thông qua:

rm .git/refs/remotes/origin/HEAD
git fetch --all

Trong trường hợp của tôi, điều đó xảy ra vì tôi đã xóa một số nhánh cục bộ và từ xa (bằng cách nào đó tệp .git / refs / remotes / origin / HEAD vẫn ở trạng thái không nhất quán). Thay đổi nội dung của tệp được đề cập ở trên để trỏ đến một nhánh cục bộ tồn tại (ví dụ: ref: refs / remotes / origin / master) đã giải quyết được vấn đề này. Tuy nhiên, cách tiếp cận trên có thể tốt hơn vì HEAD có thể trỏ đến một cam kết không có trong nhánh hiện tại.
crissdev 27/09/2016

Trong trường hợp các vấn đề xảy ra với một submodule cụ git, lệnh đầu tiên hơi thay đổi đểrm <root repository path>/.git/modules/<path to the submodule>/refs/remotes/origin/HEAD
gobe

1
Tôi đã phải làm rm -rf .git/refs/remotes/origin, nhưng u chỉ cho tôi để đi đúng hướng
Jacka

23

Bắt đầu bằng cách làm theo các bước được đề xuất trong Khôi phục kho lưu trữ git bị hỏng :

  • kiểm tra xem .git/refsvẫn còn chứa bất kỳ điều gì hữu ích
  • kiểm tra git reflogvà thất bại rằng nội dung của .git/logs/refs/heads/masterhoặc bất kỳ nhánh nào bạn đã truy cập lần trước
  • chạy git fsck, có khả năng với --unreachablehoặc--lost-found

Điều này hy vọng sẽ cho phép bạn tìm ra masterref nên là gì để bạn có thể khôi phục nó (tức là con mèo đúng SHA1 thành .git/refs/heads/master).

Trong trường hợp bất kỳ đối tượng nào trong cam kết đó thực sự bị hỏng, bạn không thể khôi phục HEADcam kết của mình . Giả sử cây làm việc và / hoặc chỉ mục của bạn còn nguyên vẹn, bạn có thể thử a git reset --soft(hoặc không thành công a git reset) đối với cam kết trước đó và sau đó thực hiện lại cam kết. Tránh bất kỳ thao tác nào làm thay đổi cây làm việc của bạn sa git checkout -fhoặc git reset --hard.


Tôi đã nhìn vào .git/logs/refs/heads/mybranch. Nó cho thấy một số loại lịch sử cam kết đối với nhánh này. Tìm hiểu kỹ về điều đó, tôi đã chọn ra các SHA và cố gắng hiển thị chúng với git show. (Mỗi lần cam kết có hai SHA, tôi đã chọn cái thứ hai, ngay trước tên tác giả.) Cái cuối cùng bị hỏng nhưng cái trước đó có thể là git shown và tôi đã có thể đẩy nó bằng git push origin abcdef:mybranch.
Ed Avis

12

Tôi đã gặp sự cố tương tự sau khi màn hình xanh chết chóc trên windows 8.1

Tôi có một tệp ở vị trí này ...

C:\www\<project>\.git\refs\remotes\origin\<problem-branch>

Và nó trống trong khi các tệp nhánh khác trong thư mục này có các chuỗi dài bên trong chúng.

NB Tôi không có bất kỳ thay đổi / cam kết nào

  • Tôi đã sao lưu <problem-branch>tệp
  • Đã xóa tệp
  • git fetch --all để lấy lại chi nhánh

Sau đó, tính năng tự động hoàn thành tab bắt đầu hoạt động trở lại


6

Nếu không có nhiều tệp được sửa đổi, tôi nghĩ rằng cách phù hợp để giải quyết vấn đề này là:

  1. sao lưu các tệp bạn đã sửa đổi trong repo
  2. xóa repo hiện có của bạn
  3. sao chép lại nó từ máy chủ
  4. dán các tệp từ bước 1 vào repo và git commit -a

vâng, không ai có thể nghĩ đến việc nhân bản lại. gợi ý tuyệt vời
Selman Genç

5

tôi đã giải quyết được vấn đề này bằng cách xóa tệp chính trong thư mục git \ refs \ heads


Điều này đã giúp ích, nó đã xóa chi nhánh khỏi danh sách của tôi trên intellij và tôi đã kiểm tra nó như một chi nhánh mới. May mắn thay, tôi đã đẩy những thay đổi của mình để chúng ở đó.
OAM

4

Sau một đóng băng tính và sụp đổ, git branch của tôi đã bị hư hỏng với thông điệp: git fatal: your current branch appears to be broken. Tôi không thể làm gì cả.

Sau khi làm git fsckđề cập rằng chi nhánh có một error: Invalid HEAD. refs/heads/<branch>có một invalid sha1 pointer.

Khi làm theo các tùy chọn ở đây, tôi đã mở .git/refs/heads/<branch>trong trình soạn thảo notepad ++ và mỗi ký tự sha1 đều như vậy NUL.

May mắn thay, tôi chỉ cần đặt lại chi nhánh về trạng thái từ xa và đó là trên một repo bitbucket. Tôi lấy sha1 từ đầu của repo từ xa và sao chép vào .git/refs/heads/<branch>tệp đã lưu, sau đó thực hiện a git reset --hard HEAD, và mọi thứ trở lại bình thường.


2

Tôi đã đủ ngốc khi quên đẩy và máy tính của tôi bị hỏng khi thực hiện cam kết. Tôi có thể khôi phục mọi thứ trừ lần cam kết cuối cùng bằng cách mở .git / logs / refs / heads /

Tệp này chứa tất cả các cam kết (với SHA của họ) đối với nhánh, những gì tôi đã làm để khôi phục là:

  • Sao lưu các thay đổi mới nhất vào thư mục tạm thời
  • chuyển sang "phương tiện chặn sạch"
    • git checkout master
    • git reset --hard
  • kiểm tra lần cam kết thứ hai đến lần cuối cùng trong nhật ký
  • tạo một nhánh từ đầu tách rời này
  • ĐẨY
  • Khôi phục các thay đổi mới nhất
  • Cam kết một lần nữa

Vì vậy, ngay cả khi bạn mắc phải một sai lầm ngớ ngẩn, bạn không phải lập tức lấy lại cả ngày làm việc với git :)


1

Tôi biết đó là một phản hồi quá muộn, nhưng tôi gặp phải lỗi này vì tôi không có origin/head. Bạn có thể tìm ra điều này bằng cách chạy git branch -r. Nếu bạn không thấy bạn origin/headtrỏ đến điểm gốc từ xa, bạn có thể thiết lập điều này bằng cách chạy git remote set-head origin {{your branch name}}.

Bây giờ chạy git branch -rlại và bạn sẽ thấy một cái gì đó như thế này: origin/HEAD -> origin/develop

Tôi hy vọng điều này sẽ giúp bất kỳ ai khác đang gặp phải vấn đề này.


1

Tôi không thể kiểm tra chi nhánh chính của mình do lỗi không thể khóa tham chiếu. Tôi đã xóa: .git/refs/remotes/origin/HEAD .git/refs/remotes/origin/master

và gọi lệnh git này:

git fetch --all

1

Thứ lỗi cho tôi nếu tôi lặp lại sau khi ai đó (tôi chưa đọc tất cả phản hồi). Theo tôi, cách đơn giản nhất để giải quyết vấn đề là sao chép dự án mà không có .git và .idea, dọn dẹp nó, sao chép từ git, xóa mọi thứ ngoại trừ các thư mục trên và sau đó dán bản sao trước đó vào kho mới được tạo bằng .git và .idea . Hy vọng nó có ý nghĩa.


1

Máy tính của tôi bị lỗi hai lần và kết quả là kho lưu trữ git của tôi bị hỏng cục bộ. Tôi không thể kéo các thay đổi của mình, nó yêu cầu đặt nguồn gốc từ xa nhưng nó không hoạt động trong gitKraken.

Trên dấu nhắc lệnh của tôi, tôi gặp lỗi này nhập mô tả hình ảnh ở đây

Tôi biết rằng các tham chiếu của tôi bị hỏng và cần được sửa. Những gì tôi phải làm là, git bash (Trong SourceTree, nhấp vào "terminal"). Sau đó điều hướng đến thư mục tham chiếu như thế này

cd .git
cd refs
cd remotes
cd origin

sẽ có một tên tệp masterở đó, sử dụng lsđể xem những gì có trong thư mục. Sau đó, chỉ cần xóa nó bằng cách sử dụng rm master

bam, tệp bị hỏng đã biến mất. Bây giờ nếu bạn phát hành lệnh git branch -a, nó sẽ xuất ra

$ git branch -a
* master
  remotes/origin/master (this in red color -scary :) )

Sau đó, phát hành lệnh này và nó sẽ sửa các tham chiếu của bạn

$ git remote set-head origin master

Tóm lại, nếu bạn cố gắng kéo điều khiển từ xa, nó sẽ hiển thị tên điều khiển trống đã được sửa.

nhập mô tả hình ảnh ở đây


0

Tôi đã gặp vấn đề tương tự nhưng không may mắn, không thể tìm ra vấn đề. Tôi đã chuyển repo của mình sang một bên, sao chép lại repo từ máy chủ và cố gắng hợp nhất giữa chúng. Tất nhiên nó hiển thị rất nhiều tệp không liên quan đến chi nhánh của tôi, nhưng giúp cô lập các tệp cần thiết.


0

Kiểm tra xem MSWindows đã tạo các tệp desktop.ini có cả hai git không? nó làm cho tôi. Khi tôi xóa tất cả chúng trong các thư mục con của thư mục .git thì nó sẽ hoạt động.


0

Tôi gặp sự cố tương tự khi Android Studio bị ngắt đột ngột (do máy tính bị mất nguồn).

Tôi đã giải quyết nó bằng cách sao chép nội dung C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\heads\mastertệp của tôi vàoC:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\remotes\origin\master tệp .

(Trước đây, tôi cũng đã bật tùy chọn 'Force Push' trong Android Studio, nhưng tôi không nghĩ đây là bước cần thiết.)

Ghi chú:

Tôi tìm thấy giải pháp này bằng cách so sánh nội dung của các tập tin trong tôi C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\thư mục (inc thư mục con.) Để các tập tin tương ứng của những người trong một khỏe mạnh dự án - ví dụ như, C:\Users\myusername\AndroidStudioProjects\MyHealthyApp\.git\.

Bạn có thể có một tệp khác bị hỏng, nhưng bằng cách so sánh với một dự án lành mạnh khác, bạn sẽ có thể nhanh chóng phát hiện ra điều gì sai.

Nếu bạn không có một dự án lành mạnh khác đã được định cấu hình git, bạn có thể nên tạo một dự án đơn giản giống như cách bạn đã tạo dự án bị hỏng của mình để có thể điều tra, so sánh và sửa chữa, v.v.

PS - Thông báo lỗi của tôi (đã chỉnh sửa) là: warning: ignoring broken refs/remotes/origin/master.fatal bad revision 'refs/remotes/origin/master..refs/heads/master' during executing git -c core.quotepath=false log refs/remotes/origin/master..refs/heads/master --pretty=format --encoding=UTF-8 -M --name-status -c --

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.