Làm thế nào để sửa lỗi GIT: tệp đối tượng trống?


442

Khi tôi cố gắng thực hiện các thay đổi, tôi gặp lỗi này:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Bất kỳ ý tưởng làm thế nào để giải quyết lỗi này?

BIÊN TẬP

Tôi đã thử git fsckTôi đã có:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

Bạn đã buộc phải giết một git addhoạt động? Đĩa cứng của bạn đã đầy chưa?
cdhowie

Không, đĩa cứng của tôi không đầy, tôi không nhớ rằng tôi đã buộc phải giết một hoạt động thêm git, nếu tôi đã làm thì sao? làm sao tôi có thể giải quyết việc này ?
simo

không, lỗi vẫn còn đó ...
simo

2
Nếu kho lưu trữ này tồn tại trên kho lưu trữ từ xa, bạn có thể thử sao chép tệp đó từ đó sang kho lưu trữ cục bộ nếu tồn tại trên kho lưu trữ từ xa.
Attila Szeremi

2
Tôi đã gặp lỗi này khi quyền của tôi trong thư mục .git bị rối loạn bằng cách nào đó và tôi không có quyền truy cập đọc. Vì vậy, nó có thể xảy ra trong trường hợp các tệp không trống nhưng chúng không thể được ghi vào. Sửa lỗi và chạy git fsckđã chăm sóc nó.
Jake Anderson

Câu trả lời:


898

Tôi đã có một vấn đề tương tự. Máy tính xách tay của tôi hết pin trong một hoạt động git. Boo.

Tôi đã không có bất kỳ bản sao lưu. (NB Ubuntu One không phải là một giải pháp sao lưu cho git; nó sẽ ghi đè một cách hữu ích kho lưu trữ lành mạnh của bạn với kho lưu trữ bị hỏng của bạn.)

Đối với các pháp sư git, nếu đây là một cách xấu để sửa nó, xin vui lòng để lại nhận xét. Nó đã làm, tuy nhiên, làm việc cho tôi ... ít nhất là tạm thời.

Bước 1: Tạo bản sao lưu của .git (thực tế tôi thực hiện việc này ở giữa mỗi bước thay đổi một cái gì đó, nhưng với một tên sao chép mới, ví dụ: .git-old-1, .git-old-2, v.v.) :

cp -a .git .git-old

Bước 2: Chạy git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Bước 3: Xóa tệp trống. Tôi đã tìm, cái quái gì; dù sao nó cũng trống.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Bước 3: Chạy git fscklại. Tiếp tục xóa các tập tin trống. Bạn cũng có thể cdvào .gitthư mục và chạy find . -type f -empty -delete -printđể xóa tất cả các tệp trống. Cuối cùng, git bắt đầu nói với tôi rằng nó thực sự đang làm gì đó với các thư mục đối tượng:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Bước 4: Sau khi xóa tất cả các tệp trống, cuối cùng tôi đã git fsckthực sự chạy:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Bước 5: Thử git reflog. Thất bại vì ĐẦU của tôi bị hỏng.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Bước 6: Google. Tìm này . Nhận thủ công hai dòng cuối cùng của reflog:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400  commit: fixed up to page 28

Bước 7: Lưu ý rằng từ Bước 6, chúng tôi đã biết rằng CHÍNH hiện đang chỉ đến cam kết cuối cùng. Vì vậy, hãy cố gắng chỉ nhìn vào cam kết của phụ huynh:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

Nó đã làm việc!

Bước 8: Vì vậy, bây giờ chúng ta cần trỏ TRÊN 9f0abf890b113a287e10d56b66dbab66adc1662d.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Mà không phàn nàn.

Bước 9: Xem những gì fsck nói:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Bước 10: Con trỏ sha1 không hợp lệ trong cây bộ đệm có vẻ như là từ một tệp chỉ mục (hiện đã lỗi thời) ( nguồn ). Vì vậy, tôi đã giết nó và thiết lập lại repo.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Bước 11: Nhìn lại fsck ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

Các đốm màu lơ lửng không có lỗi . Tôi không quan tâm đến master.u1 Conflict, và bây giờ nó đang hoạt động tôi không muốn chạm vào nó nữa!

Bước 12: Bắt kịp với các chỉnh sửa tại địa phương của tôi:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Vì vậy, hy vọng rằng có thể được sử dụng cho mọi người trong tương lai. Tôi rất vui vì nó đã làm việc.


86
Câu trả lời tuyệt vời, cùng với tất cả các bước và tất cả. Tôi cho rằng bạn đã cứu tôi khỏi việc googling từng người một!
Zlatko

24
Làm việc như người ở! Tôi ước tôi có thể nâng cấp điều này nhiều lần;)
MarcDefiant

1
Hmm, máy tính xách tay của tôi đã chết trong một hoạt động git (SparkleShare đã cố gắng ghi chú của tôi khi nó chết) và sau đó repo đã bị hỏng theo cách này. Tôi đã làm theo các bước của bạn cho đến 6 nhưng có vẻ như một số cam kết cuối cùng thực sự được cho là một phần của các tệp đối tượng trống mà tôi đã xóa? Trong thực tế, 3 lần cam kết cuối cùng về cơ bản đã bị phá vỡ hoàn toàn nên tôi đoán tôi không thể làm gì được. May mắn thay, tôi thực sự không cần các cam kết cá nhân từ SparkleShare và tôi chỉ có thể sao chép tệp bẩn từ máy này sang máy khác và hợp nhất.
Ibrahim

14
Tuyệt vời, câu trả lời tuyệt vời. Cảm ơn đặc biệt bao gồm cả lý do của bạn đằng sau mỗi bước. Bạn đã lưu repo của tôi! (Vâng, tôi vẫn còn có một 'ref xấu cho refs / con / chủ' lỗi từ fsck, nhưng đó là tương đối nhẹ.)
Jon Carter

3
Cảm ơn, tôi đã học được rất nhiều về một số chức năng của git đồng thời tiết kiệm thịt xông khói của tôi trên một cam kết quan trọng! Thật trùng hợp, đó cũng là do pin yếu trên laptop.
HarbyUK

195

Các tệp đối tượng git đã bị hỏng (như được chỉ ra trong các câu trả lời khác). Điều này có thể xảy ra trong các sự cố máy, vv

Tôi đã có thứ tương tự. Sau khi đọc các câu trả lời hàng đầu khác ở đây, tôi đã tìm ra cách nhanh nhất để sửa lỗi kho git bị hỏng bằng các lệnh sau (thực hiện trong .gitthư mục git làm việc có chứa thư mục):

(Hãy chắc chắn sao lưu thư mục kho git của bạn trước!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

Điều này trước tiên sẽ xóa toàn bộ tệp đối tượng trống gây ra lỗi toàn bộ kho lưu trữ, sau đó tìm nạp các đối tượng bị thiếu (cũng như các thay đổi mới nhất) khỏi kho lưu trữ từ xa, sau đó thực hiện kiểm tra lưu trữ đối tượng đầy đủ . Mà tại thời điểm này, sẽ thành công mà không có bất kỳ lỗi nào (mặc dù vẫn có thể có một số cảnh báo!)

Tái bút Câu trả lời này gợi ý bạn có một bản sao từ xa của kho git của bạn ở đâu đó (ví dụ trên GitHub) và kho lưu trữ bị hỏng là kho lưu trữ cục bộ được gắn với kho lưu trữ từ xa vẫn còn trong chiến thuật. Nếu đó không phải là trường hợp, thì đừng cố gắng sửa nó theo cách tôi khuyên.


Cảm ơn vì điều này, tôi khá tôn trọng đẩy đến các chi nhánh từ xa của mình và giải pháp của bạn đã làm việc cho tôi. Tôi đã thử @ mCorr dưới đây trước nhưng sau khi tôi cam kết các tệp mới, repo trở lại bị hỏng. Cách tiếp cận này đã giải quyết nó
mr_than

như hầu hết có một điều khiển từ xa. Giải pháp này thực sự sạch sẽ và đầy đủ.
jackOf ALL 23/1/2017

7
Có vấn đề này sau khi tắt một VM trong đó tôi đang làm việc với một repo git. Giải pháp này hoạt động hoàn hảo.
Giscard Biamby

Cảm ơn Martin, giải pháp tuyệt vời và nhỏ gọn. Mặc dù tôi có thể đặt PS đó lên trước, với cảnh báo được in đậm, để ngăn người dùng ngây thơ thử điều tương tự trên một thiết lập chỉ cục bộ. Giống như Giscard, điều này phát sinh đối với tôi khi tắt VM ... sẽ cập nhật nếu tôi tìm thấy giải pháp lâu dài hơn là thực hiện điều này mỗi lần.
thclark

2
Một VM VM đã làm điều này với repo git địa phương của tôi, tôi có thể xác nhận rằng giải pháp này hoạt động 100% trong trường hợp đó
Amin.T

35

Lỗi này xảy ra với tôi khi tôi đang thực hiện cam kết và máy tính của tôi bị treo. Đây là cách tôi sửa nó.


Các bước khắc phục

git status

hiển thị tệp đối tượng trống / hỏng

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

loại bỏ nó

git status

Tôi nhận được fatal: bad object HEADtin nhắn

rm .git/index

Tôi loại bỏ indexđể thiết lập lại

git reset

gây tử vong: Không thể phân tích đối tượng 'ĐẦU'.

git status
git pull

chỉ để kiểm tra những gì đang xảy ra

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

in 2 dòng cuối cùng tail -n 2của nhánh log để hiển thị 2 dòng cuối cùng của tôicommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Tôi chọn cái cuối cùng commit hash

git status

hiển thị tất cả các tập tin của tôi deletedvì tôi đã xóa .git/indextập tin

git reset

tiếp tục thiết lập lại

git status

xác minh sửa chữa của tôi


Lưu ý: Các bước bắt đầu khi tôi trả lời câu hỏi này và sử dụng các câu trả lời làm tài liệu tham khảo.


34

Tôi đã giải quyết vấn đề này bằng cách loại bỏ các tệp trống khác nhau mà git fsck đang phát hiện, và sau đó chạy một git pull đơn giản.

Tôi thấy thật đáng thất vọng khi bây giờ ngay cả các hệ thống tập tin thực hiện ghi nhật ký và các kỹ thuật "giao dịch" khác để giữ cho fs lành mạnh, git có thể chuyển sang trạng thái bị hỏng (và không thể tự phục hồi) do mất điện hoặc không gian trên thiết bị.


3
Tôi chắc chắn rằng câu trả lời ở trên là tốt hơn về mặt kỹ thuật, nhưng nó đã ngừng hoạt động ở bước 6 và vượt xa đầu tôi về mặt kỹ thuật. Cách tiếp cận nhanh chóng là git pull
mblackwell8

2
Tôi đã gặp một tình huống trong đó, sau khi thực hiện các bước 1-11 của hướng dẫn từ câu trả lời của Nathan (rất hiệu quả!), Tôi đã gặp lỗi khi nói refs / origin / master và refs / origin / head không được xác định (hoặc đại loại như cái đó). Git kéo cố định mà. Vì vậy, tôi nghĩ rằng cả hai giải pháp làm việc cùng nhau.
beclill

2
Tôi biết rằng các hệ thống tập tin được sử dụng thường chỉ ghi nhật ký siêu dữ liệu. Bạn cũng có thể bật nhật ký cho dữ liệu, nhưng tôi đoán nó không mặc định do chi phí hoạt động (?) Đó có thể là lý do tại sao các tệp trống .... và hệ thống tệp thường quan sát các giao dịch trên mỗi tệp, trong khi git có nhiều tệp được sửa đổi trên mỗi giao dịch, do đó, ngay cả khi fs giữ tính nhất quán cho mỗi tệp, nếu git không, thì tôi đoán git sẽ dẫn đến trạng thái không nhất quán ...
Heartinunch

Câu trả lời này làm việc cho tôi, những người khác là cách phức tạp.
ldog

1
Cách giải quyết nhanh hơn câu trả lời được chấp nhận. Đối với tất cả những người đã di chuyển đến đây, hãy làm theo câu trả lời này nếu bạn đang vội.
Sri Harsha Kappala

9

Tôi chỉ gặp vấn đề tương tự: sau khi kéo kho lưu trữ ở xa, khi tôi thực hiện trạng thái git tôi nhận được: "error: tệp đối tượng (...) trống" "fatal: lỏng object (...) bị hỏng"

Cách tôi giải quyết điều này là:

  1. git stash
  2. xóa tệp git bị lỗi (không chắc chắn là cần thiết)
  3. git rõ ràng

Tôi không biết chính xác những gì đã xảy ra, nhưng hướng dẫn đó dường như làm cho mọi thứ sạch sẽ.


2
Tôi luôn thích các câu trả lời đơn giản hơn :) Đối với Bước 2 ở đây, tôi đã sử dụng lệnh được cung cấp trong câu trả lời của cd .git/ && find . -type f -empty -delete
@Nathan VanHoudnos

8

Bởi vì tôi phải khởi động lại VM thường xuyên, nên bằng cách nào đó, vấn đề này xảy ra với tôi rất thường xuyên. Sau vài lần, tôi nhận ra rằng tôi không thể lặp lại quy trình được mô tả bởi @ Nathan-Vanhoudnos mỗi khi điều này xảy ra, mặc dù nó luôn hoạt động. Sau đó, tôi tìm ra giải pháp nhanh hơn sau đây.

Bước 1

Di chuyển toàn bộ repo của bạn vào một thư mục khác.

mv current_repo temp_repo

Bước 2

Nhân bản repo từ nguồn gốc một lần nữa.

git clone source_to_current_repo.git

Bước 3

Xóa mọi thứ trong repo mới ngoại trừ thư mục .git .

Bước 4

Di chuyển Tất cả mọi thứ từ temp_repo đến repo mới trừ các .git thư mục.

Bước 5

Xóa temp numpo , và chúng ta đã hoàn thành.

Sau vài lần, tôi chắc chắn bạn có thể làm thủ tục này rất nhanh.


2
Hoặc không di chuyển repo hiện tại của bạn, 1) tạo bản sao mới git clone source_to_current_repo.git clean_repo, 2) sao lưu thư mục .git cũ, 3) sao chép vào thư mục .git sạch.
moi

Bạn đúng rồi. Tôi đã làm nó bây giờ. Sẽ chỉnh sửa câu trả lời sau.
haoqiang

@haoqiang: Bạn đã viết "Vì tôi phải khởi động lại VM thường xuyên, nên bằng cách nào đó, vấn đề này xảy ra với tôi rất thường xuyên." Chúng tôi trải nghiệm như nhau. Bạn đã thực hiện bất kỳ tiến triển nào về nguyên nhân gốc - Cài đặt VM khiến sự cố ít xảy ra hơn?
hansfn

6
  1. mv ứng dụng thư mục của bạn để tạo bản sao lưu, tức là mv app_folder app_folder_bk (nó giống như một git stash )
  2. git nhân bản thông tin của bạn
  3. Cuối cùng ,. Mở một công cụ hợp nhất (tôi sử dụng meld diff viewer linux hoặc Winmerge Windows) và sao chép các thay đổi từ phải ( app_folder_bk ) sang trái ( app_folder mới ) (giống như áp dụng git stash ).

Đó là tất cả. Có thể nó không phải là cách tốt nhất, nhưng tôi nghĩ nó rất thiết thực.


1
Đây là những gì bạn nên làm khi tất cả các thay đổi cục bộ được đẩy lên thượng nguồn hoặc các thay đổi là tối thiểu, do đó nhân bản nhanh hơn phục hồi.
mu

3

Trong trường hợp của tôi, lỗi này xảy ra do tôi đang gõ tin nhắn cam kết và sổ ghi chép của tôi đã tắt.

Tôi đã làm các bước sau để sửa lỗi:

  • git checkout -b backup-branch # Tạo một nhánh dự phòng
  • git reset --hard HEAD~4# Đặt lại cam kết nơi mọi thứ hoạt động tốt. Trong trường hợp của tôi, tôi đã phải lùi lại 4 lần xác nhận trong đầu, đó là cho đến khi đầu tôi ở điểm trước khi tôi gõ tin nhắn cam kết. Trước khi thực hiện bước này, hãy sao chép hàm băm của các xác nhận bạn sẽ đặt lại, trong trường hợp của tôi, tôi đã sao chép hàm băm của 4 lần xác nhận cuối cùng
  • git cherry-pick <commit-hash> # Cherry chọn các cam kết được đặt lại (trong trường hợp của tôi là 4 lần xác nhận, vì vậy tôi đã thực hiện bước này 4 lần) từ nhánh cũ sang nhánh mới.
  • git push origin backup-branch # Đẩy chi nhánh mới để đảm bảo mọi thứ hoạt động tốt
  • git branch -D your-branch # Xóa chi nhánh cục bộ ('chi nhánh của bạn' là chi nhánh có vấn đề)
  • git push origin :your-branch # Xóa chi nhánh từ xa
  • git branch -m backup-branch your-branch # Đổi tên nhánh sao lưu để có tên của nhánh có vấn đề
  • git push origin your-branch # Đẩy chi nhánh mới
  • git push origin :backup-branch # Xóa nhánh sao lưu từ xa

3
git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

giải quyết vấn đề của tôi


Điều này đã giúp. Cảm ơn bạn.
swateek

Nếu repo sạch, bạn chỉ cần "cd .git / && find. -Ape f -empty -delete && cd - && git pull", bạn có thể cần kiểm tra một số tệp trong git statuskhi một số tệp trống.
CodyChan

2

Đây là một cách thực sự đơn giản và nhanh chóng để giải quyết vấn đề này NẾU bạn có một repo cục bộ với tất cả các chi nhánh và cam kết bạn cần, và nếu bạn ổn với việc tạo một repo mới (hoặc xóa repo của máy chủ và tạo một repo mới ở chỗ của nó):

  1. Tạo một repo trống mới trên máy chủ (hoặc xóa repo cũ và tạo một repo mới ở vị trí của nó)
  2. Thay đổi URL từ xa của bản sao cục bộ của bạn để trỏ đến URL từ xa của repo mới.
  3. Đẩy tất cả các chi nhánh từ repo cục bộ của bạn sang repo máy chủ mới.

Điều này bảo tồn tất cả lịch sử cam kết và các chi nhánh mà bạn có trong repo địa phương của bạn.

Nếu bạn có cộng tác viên trên repo, thì tôi nghĩ trong nhiều trường hợp tất cả các cộng tác viên của bạn phải làm là thay đổi URL từ xa của repo cục bộ của họ, và tùy ý đẩy bất kỳ cam kết nào họ có mà máy chủ không có.

Giải pháp này hiệu quả với tôi khi tôi gặp phải vấn đề tương tự. Tôi đã có một cộng tác viên. Sau khi tôi đẩy repo cục bộ của mình sang repo từ xa mới, anh ấy chỉ cần thay đổi repo cục bộ của mình để trỏ đến URL repo từ xa và mọi thứ đều hoạt động tốt.


2

Tôi giả sử bạn có một điều khiển từ xa với tất cả các thay đổi có liên quan đã được đẩy tới nó. Tôi không quan tâm đến những thay đổi cục bộ và chỉ đơn giản là muốn tránh xóa và truy xuất một kho lưu trữ lớn. Nếu bạn có những thay đổi cục bộ quan trọng, bạn có thể muốn cẩn thận hơn.

Tôi đã có vấn đề tương tự sau khi máy tính xách tay của tôi bị hỏng. Có lẽ bởi vì đó là một kho lưu trữ lớn, tôi có khá nhiều tệp đối tượng bị hỏng, chúng chỉ xuất hiện một lần khi gọi git fsck --full, vì vậy tôi đã viết một lớp vỏ nhỏ để tự động xóa một trong số chúng:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

  • 2>&1 chuyển hướng thông báo lỗi đến thiết bị xuất chuẩn để có thể grep nó
  • tùy chọn grep được sử dụng:
    • -o chỉ trả về một phần của dòng thực sự khớp
    • -E cho phép các biểu thức nâng cao
    • -m 1 đảm bảo chỉ có trận đấu đầu tiên được trả lại
    • [0-9a-f]{2} khớp với bất kỳ ký tự nào trong khoảng từ 0 đến 9 và a và f nếu hai trong số chúng xuất hiện cùng nhau
    • [0-9a-f]* khớp với bất kỳ số lượng ký tự nào từ 0 đến 9 và a và f xuất hiện cùng nhau

Nó vẫn chỉ xóa một tệp tại một thời điểm, vì vậy bạn có thể muốn gọi nó trong một vòng lặp như:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Vấn đề với điều này là, nó không xuất ra bất cứ thứ gì hữu ích nữa nên bạn không biết khi nào nó kết thúc (nó sẽ không làm gì hữu ích sau một thời gian)

Để "sửa" điều này, sau đó tôi chỉ cần thêm một cuộc gọi git fsck --fullsau mỗi vòng như vậy: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Bây giờ nó nhanh gấp rưỡi, nhưng nó tạo ra "trạng thái".

Sau đó, tôi đã chơi xung quanh một số với các đề xuất trong chủ đề này và cuối cùng đã đến một điểm mà tôi có thể git stashgit stash droprất nhiều thứ bị hỏng.

vấn đề đầu tiên được giải quyết

Sau đó tôi vẫn gặp vấn đề sau: unable to resolve reference 'refs/remotes/origin/$branch': reference brokencó thể giải quyết bằng $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Sau đó tôi đã làm một $ git gc --prune=now

$ git remote prune origin

cho các biện pháp tốt và

git reflog expire --stale-fix --all

để thoát khỏi error: HEAD: invalid reflog entry $blubbkhi chạy git fsck --full.


2

Chúng ta hãy đơn giản .. chỉ trường hợp bạn đã tải nguồn lên repo git từ xa

  1. Sao lưu .git của bạn
  2. kiểm tra git của bạn

    git fsck --full
    
  3. xóa tệp đối tượng trống (tất cả)

    rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
    
  4. kiểm tra lại git của bạn

    git fsck --full
    
  5. lấy nguồn của bạn từ git từ xa

    git pull origin master
    

2

Tôi gặp vấn đề này rất nhiều với các máy ảo.

Đối với tôi các tác phẩm sau:

cd /path/to/your/project
rm -rf .git

Nếu bạn muốn tự lưu lại một số phần tải xuống - hãy vào trình thám hiểm tệp của bạn và xóa tất cả các tệp trong thư mục đã được cam kết và để lại trong thư mục / nhà cung cấp và / node_modules (tôi làm việc với các thư mục soạn thảo và npm).

sau đó chỉ cần tạo một repo mới

git init

thêm điều khiển từ xa của bạn

git remote add origin ssh://git@github.com/YourUsername/repoName.git

và lấy chi nhánh / tất cả của nó

git fetch origin somebranch

và kiểm tra nó

git checkout somebranch

sau đó bạn nên ở điểm trước khi lỗi.

Hi vọng điêu nay co ich.

Trân trọng.


1

Tôi gặp phải vấn đề tương tự, và tôi sử dụng một cách rất đơn giản để khắc phục nó. Tôi thấy rằng những tập tin bị thiếu đó tồn tại trên máy tính của đồng đội của tôi.

Tôi đã sao chép từng tệp một vào máy chủ git (tổng cộng 9 tệp) và điều đó đã khắc phục được sự cố.


1

Các đồng nghiệp của tôi và tôi đã vượt qua nhiều lần với cùng một vấn đề này và để giải quyết nó, chúng tôi chỉ cần thực hiện các bước mà tôi mô tả dưới đây. Nó không phải là giải pháp tao nhã nhất có thể được tìm thấy nhưng nó hoạt động mà không mất dữ liệu.

  1. Đổi tên thư mục làm việc hiện tại. ( old_projectví dụ này).
  2. Nhân bản kho lưu trữ trong một thư mục mới bằng cách sử dụng git clone.
  3. Trên dòng lệnh, thay đổi thư mục làm việc sang dự án vừa tạo và chuyển sang nhánh bạn đang làm việc.
  4. Sao chép tất cả các tệp và thư mục trong old_project(trừ .gitthư mục) vào thư mục dự án mới được tạo.
  5. Kiểm tra trạng thái cây làm việc của bạn (lưu ý rằng có nhiều thay đổi hơn bạn mong đợi) và sau đó cam kết thay đổi.

Tôi hy vọng nó sẽ giúp ...


1

Đây là một cách để giải quyết vấn đề nếu repo công khai của bạn trên github.com đang hoạt động, nhưng repo cục bộ của bạn bị hỏng. Hãy lưu ý rằng bạn sẽ mất tất cả các cam kết bạn đã thực hiện trong repo địa phương.

Được rồi, vì vậy tôi có một repo tại địa phương đang đưa cho tôi cái này object empty error và cùng một repo trên github.com, nhưng không có lỗi này. Vì vậy, những gì tôi chỉ đơn giản là sao chép repo đang hoạt động từ github, sau đó sao chép mọi thứ từ repo bị hỏng (ngoại trừ thư mục .git) và dán vào repo nhân bản đang hoạt động.

Đây có thể không phải là một giải pháp thực tế (vì bạn xóa các xác nhận cục bộ), tuy nhiên, bạn vẫn duy trì mã và kiểm soát phiên bản đã sửa chữa.

Hãy nhớ sao lưu trước khi áp dụng phương pháp này.


1

Trong trường hợp của tôi, điều quan trọng đối với tôi là giữ lịch sử cam kết địa phương. Vì vậy, nếu điều đó cũng áp dụng cho bạn, bạn có thể thực hiện việc này như một giải pháp thay thế nhanh chóng cho các giải pháp trên:

Về cơ bản, bạn chỉ cần thay thế .git/thư mục bị hỏng bằng một thư mục sạch.

Hãy giả sử thư mục sau cho dự án của bạn với git bị hỏng: projects/corrupt_git/

  1. cp projects/corrupt_git projects/backup - (tùy chọn) tạo bản sao lưu
  2. git clone [repo URL] projects/clean_git - để bạn có được projects/clean_git
  3. rm -rf corrupt_git/.git/ - xóa thư mục .git bị hỏng
  4. mv clean_git/.git/ corrupt_git/ - di chuyển git sạch đến corrupt_git/.git
  5. git statustrong projects/corrupt_git- để đảm bảo nó hoạt động

0

Sao chép mọi thứ (trong thư mục chứa .git) vào bản sao lưu, sau đó xóa mọi thứ và khởi động lại. Hãy chắc chắn rằng bạn có git từ xa tiện dụng:

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

Sau đó

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

Sau đó, hợp nhất bất kỳ tệp mới nào theo cách thủ công và cố gắng giữ cho máy tính của bạn được bật.


rm -rf * có thể có hậu quả rất xấu. Bạn đã thực sự có ý đó?
tommyk

@tommyk do đó sao chép vào bản sao lưu đầu tiên. Tôi đoán rằng lực lượng không cần thiết.
Shelvacu

0

Có vấn đề tương tự sau khi kiểm tra tổng thể từ một chi nhánh sạch. Sau một thời gian, tôi nhận ra rất nhiều tập tin sửa đổi trong master. Tôi không biết tại sao họ lại ở đó, sau khi chuyển từ một nhánh sạch. Dù sao đi nữa, vì các tập tin sửa đổi không có ý nghĩa với tôi, tôi chỉ cần lưu trữ chúng và lỗi đã biến mất.

git:(master) git stash


0

nếu bạn có bản sao lưu OLD và đang vội:

tạo BACKUP MỚI cho đường dẫn dự án hiện tại, bị hỏng của bạn.

  1. di chuyển của bạn .git vào thùng rác (không bao giờ xóa)
  2. sao chép .gittừ bản sao lưu OLD
  3. git pull (sẽ tạo xung đột hợp nhất)
  4. di chuyển tất cả các nguồn của bạn (mọi thứ bạn bỏ vào git) vào thùng rác: ./src (không bao giờ xóa)
  5. .copy tất cả các nguồn của bạn (mọi thứ bạn đặt trong git) từ BACKUP MỚI
  6. chấp nhận tất cả "hợp nhất" tại git gui, đẩy và ... vỗ tay!

0

Giải pháp mười hai bước được đề cập ở trên cũng giúp tôi thoát khỏi tình trạng kẹt xe. Cảm ơn. Các bước chính là để nhập:

git fsck --full 

và loại bỏ tất cả các đối tượng trống

rm .git/objects/...

Sau đó nhận được hai dòng của flog:

tail -n 2 .git/logs/refs/heads/master

Với các giá trị được trả về

git update-ref HEAD ...

Tại thời điểm này tôi không còn lỗi nữa, vì vậy tôi đã tạo một bản sao lưu các tệp gần đây nhất của mình. Sau đó thực hiện một động tác kéo git theo sau là một cú đẩy git. Sao chép các bản sao lưu của tôi vào tệp kho git của tôi và thực hiện một lần đẩy git khác. Điều đó đã cho tôi hiện tại.


0

Tôi đã sửa lỗi git của mình: tệp đối tượng trống bằng cách:

  1. Lưu một bản sao của tất cả các tệp mà tôi đã chỉnh sửa kể từ lần cam kết / đẩy thành công cuối cùng của mình,
  2. Xóa và sao chép lại kho lưu trữ của tôi,
  3. Thay thế các tập tin cũ bằng các tập tin chỉnh sửa của tôi.

Hy vọng điều này sẽ giúp.


0

Điều này cũng xảy ra với tôi gần như thường xuyên. Không thực hiện được một giao thức khi điều này xảy ra chính xác, nhưng tôi có một nghi ngờ rằng nó xảy ra bất cứ khi nào máy ảo của tôi tồn tại "bất ngờ". Nếu tôi đóng cửa sổ VM (tôi đang sử dụng Ubuntu 18.04) và bắt đầu lại, mọi thứ luôn luôn (?) Hoạt động. Nhưng nếu cửa sổ VM vẫn mở khi máy tính xách tay của tôi bị tắt (hệ thống máy chủ Windows), thì tôi gặp phải vấn đề này khá thường xuyên.

Như tất cả các câu trả lời được đưa ra ở đây:

  1. cảm ơn bạn - chúng rất hữu ích; Tôi thường lưu một bản sao mã cục bộ của mình, khôi phục repo từ xa và di chuyển bản sao lưu trở lại vào thư mục cục bộ.

  2. vì vấn đề cơ bản không thực sự là vấn đề git, mà là vấn đề VM và / hoặc Linux, tôi tự hỏi liệu không nên có cách nào để chữa lý do chứ không phải là triệu chứng? Không phải loại lỗi này chỉ ra rằng một số thay đổi hệ thống tệp không được "áp dụng" trong bất kỳ thời gian hợp lý nào, mà chỉ được lưu trong bộ nhớ cache? (xem ví dụ /unix/464184/are-file-edits-in-linux-directly-satted-into-disk ) - với tôi nó xuất hiện như thể các máy Linux ảo không fsynch công cụ của họ thường xuyên đủ. Cho dù đây là sự cố của VirtualBox của Oracle (hoạt động rất độc đáo) hoặc của hệ thống tệp khách hoặc một số cài đặt mà tất cả chúng ta bỏ qua, đều nằm ngoài chuyên môn của tôi. Nhưng tôi sẽ rất vui nếu ai đó có thể làm sáng tỏ điều này.


0

Thật ra tôi cũng có vấn đề tương tự. Có một bản sao mã của bạn trước khi thử điều này.

tôi vừa làm git reset HEAD~

cam kết cuối cùng của tôi đã được hoàn tác sau đó tôi cam kết lại, vấn đề đã được giải quyết!


-5

Cảnh báo: Với nhiều kinh nghiệm hơn, tôi nhận ra rằng đây là tùy chọn hạt nhân và thường không nên thực hiện và không dạy gì cả. Tuy nhiên, trong những dịp hiếm hoi cho các dự án cá nhân, tôi vẫn thấy nó hữu ích, vì vậy tôi sẽ từ bỏ nó.

Nếu bạn không quan tâm đến việc giữ các cam kết lịch sử của mình, hãy chạy

rm -r .git

Sau đó trả lời có cho bất cứ điều gì hỏi về việc xóa các tệp được bảo vệ ghi. Vấn đề được giải quyết trong một phút.


3
Đừng làm điều này nếu bạn muốn lịch sử của bạn trong chiến thuật.
mu
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.