जीआईटी त्रुटि कैसे ठीक करें: ऑब्जेक्ट फ़ाइल खाली है?

442

जब मैं बदलाव करने की कोशिश करता हूं, मुझे यह त्रुटि मिलती है:

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

किसी भी विचार कैसे इस त्रुटि को हल करने के लिए?

संपादित करें

मैंने कोशिश की है git fsckमुझे मिल गया है:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt
git 
— simo
स्रोत
क्या आपने जबरन किसी git addऑपरेशन को अंजाम दिया? क्या आपकी हार्ड डिस्क भरी हुई है?
— cdhowie
नहीं, मेरी हार्ड डिस्क पूरी नहीं है, मुझे याद नहीं है कि मैंने जबरन एक गिट ऐड ऑपरेशन को मार दिया था, अगर मैंने किया तो क्या होगा? इसे कैसे हल किया जा सकता है ?
— सिमो
नहीं, त्रुटि अभी भी है ...
— जूलो
2
यदि यह रिपॉजिटरी किसी दूरस्थ रिपॉजिटरी पर मौजूद है, तो आप उस फाइल को वहां से अपने स्थानीय एक में कॉपी करने की कोशिश कर सकते हैं यदि आपके रिमोट रिपॉजिटरी में मौजूद है।
— अत्तिला सेजेमेरी
2
मुझे यह त्रुटि तब मिली जब .गित निर्देशिका में मेरी अनुमति किसी तरह खराब हो गई और मैंने पहुंच नहीं पढ़ी। तो यह उन मामलों में भी हो सकता है जहां फाइलें खाली नहीं हैं, लेकिन उन्हें सिर्फ लिखा नहीं जा सकता है। अनुमतियाँ तय करना और चलाना इसकी git fsckदेखभाल करता था।
— जेक एंडरसन

जवाबों:

900

मुझे भी ऐसी ही समस्या का समाधान करना पड़ा था। एक ऑपरेशन के दौरान मेरा लैपटॉप बैटरी से बाहर चला गया। बू।

मेरे पास कोई बैकअप नहीं था। (एनबी उबंटू वन गिट के लिए एक बैकअप समाधान नहीं है; यह आपके भ्रष्ट प्रतिनिधि के साथ आपकी समझदारी रिपॉजिटरी को अधिलेखित करने में मदद करेगा।)

गिट जादूगरों के लिए, अगर यह इसे ठीक करने का एक बुरा तरीका था, तो कृपया एक टिप्पणी छोड़ दें। हालांकि, इसने मेरे लिए काम किया ... कम से कम अस्थायी रूप से।

चरण 1: .गित का एक बैकअप बनाएं (वास्तव में मैं हर कदम के बीच ऐसा करता हूं जो कुछ बदलता है, लेकिन एक नई कॉपी-टू नाम के साथ, उदाहरण के लिए ।गित-पुराना -1, .गित-पुराना -2, आदि।) : 

cp -a .git .git-old

चरण 2: भागो 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

चरण 3: खाली फ़ाइल निकालें। मुझे लगा कि बिल्ली क्या है; वैसे भी यह खाली है।

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

चरण 3: git fsckफिर से चलाएँ । खाली फ़ाइलों को हटाना जारी रखें। आप निर्देशिका cdमें भी जा सकते हैं .gitऔर find . -type f -empty -delete -printसभी खाली फ़ाइलों को निकालने के लिए दौड़ सकते हैं। आखिरकार गिट ने मुझे बताना शुरू कर दिया कि यह वास्तव में ऑब्जेक्ट निर्देशिकाओं के साथ कुछ कर रहा था:

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

चरण 4: सभी खाली फ़ाइलों को हटाने के बाद, मैं अंततः git fsckवास्तव में चल रहा था:

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

चरण 5: प्रयास करें git reflog। विफल क्योंकि मेरा हेड टूट गया है।

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

चरण 6: Google। यह पता लगाएं । मैन्युअल रूप से अंतिम दो रेखाएँ प्राप्त करें:

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

चरण 7: ध्यान दें कि चरण 6 से हमने सीखा कि HEAD वर्तमान में बहुत ही अंतिम ओर इशारा कर रहा है। तो चलिए जनक वचन को देखने की कोशिश करते हैं:

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

इसने काम कर दिया!

चरण 8: इसलिए अब हमें HEAD को 9f0abf890b113a287e10d56b66db6666cc1662d पर इंगित करना होगा। 

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

जिसे शिकायत नहीं थी।

चरण 9: देखें कि 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!
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

चरण 10: कैश-ट्री में अमान्य sha1 पॉइंटर ऐसा लग रहा था कि यह एक (अब पुराना) इंडेक्स फ़ाइल ( स्रोत ) से था। इसलिए मैंने इसे मार दिया और रेपो को रीसेट कर दिया।

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

चरण 11: फिर से 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

झूलते धब्बे त्रुटियां नहीं हैं । मैं Master.u1conflict से संबंधित नहीं हूं, और अब यह काम कर रहा है मैं इसे और नहीं छूना चाहता हूं!

चरण 12: मेरे स्थानीय संपादन के साथ पकड़: 

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

तो उम्मीद है कि भविष्य में लोगों के लिए कुछ काम का हो सकता है। मुझे खुशी है कि इसने काम किया।

— नाथन वनहुडनोस
स्रोत
86
उत्कृष्ट उत्तर, सभी चरणों और सभी के साथ। मुझे लगता है कि तुम मुझे उन लोगों में से हर एक को बचाने से बचा लिया!
— ज़्लाटको
24
एक जादू की तरह काम किया! मेरी इच्छा है कि मैं इसे कई बार
— बढ़ा सकूं
1
हम्म, मेरे लैपटॉप की एक जीआईटी ऑपरेशन के दौरान मृत्यु हो गई (स्पार्कलेश मेरे नोटों को मरने के रूप में करने की कोशिश कर रहा था) और उसके बाद इस तरह से रेपो भ्रष्ट हो गया था। मैंने आपके चरण 6 तक का पालन किया, लेकिन ऐसा लगता है कि पिछले कई कमिट्स वास्तव में खाली ऑब्जेक्ट फ़ाइलों का हिस्सा थे जिन्हें मैंने हटा दिया था? वास्तव में पिछले 3 कमिट मूल रूप से पूरी तरह से टूटे हुए थे इसलिए मुझे लगता है कि कुछ भी नहीं था जो मैं कर सकता था। सौभाग्य से मुझे वास्तव में स्पार्कलशेयर से व्यक्तिगत आवागमन की आवश्यकता नहीं है और मैं सिर्फ एक मशीन से दूसरी मशीन में गंदी फ़ाइल की प्रतिलिपि बना सकता हूं और विलय कर सकता हूं।
— इब्राहिम
14
बहुत बढ़िया, जबरदस्त जवाब। प्रत्येक चरण के पीछे अपने तर्क को शामिल करने के लिए विशेष रूप से धन्यवाद। आपने मेरा रेपो बचा लिया है! (ठीक है, मेरे पास अभी भी fsck से 'रेफ्स / हेड्स / मास्टर' एरर के लिए 'खराब रेफरी' है, लेकिन यह अपेक्षाकृत हल्का है।)
— जॉन कार्टर
3
धन्यवाद, मैंने कुछ गित कार्यक्षमता के बारे में बहुत कुछ सीखा, साथ ही एक महत्वपूर्ण वचन पर अपने बेकन को बचाते हुए! संयोग से यह लैपटॉप पर कम बैटरी के कारण भी था।
— हरब्युक
195

गिट ऑब्जेक्ट फाइलें भ्रष्ट हो गई हैं (जैसा कि अन्य उत्तरों में भी बताया गया है)। यह मशीन क्रैश आदि के दौरान हो सकता है।

मेरे साथ भी यही बात हुई थी। अन्य शीर्ष उत्तरों को पढ़ने के बाद, मैंने टूटी गिट रिपॉजिटरी को ठीक करने के लिए निम्नलिखित कमांड के साथ सबसे तेज़ तरीका ढूंढा (जीआईटी वर्किंग डायरेक्टरी में निष्पादित करें जिसमें .gitफ़ोल्डर शामिल है ):

(पहले अपने git रिपॉजिटरी फ़ोल्डर का बैकअप लेना सुनिश्चित करें!)

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

यह पहले किसी भी खाली ऑब्जेक्ट फ़ाइलों को हटा देगा जो कि रिपॉजिटरी के भ्रष्टाचार का कारण बनते हैं, और फिर दूरस्थ रिपॉजिटरी से लापता वस्तुओं (साथ ही नवीनतम परिवर्तनों) को नीचे लाते हैं और फिर एक पूर्ण ऑब्जेक्ट स्टोर चेक करते हैं । जो, इस बिंदु पर, बिना किसी त्रुटि के सफल होना चाहिए (हालांकि अभी भी कुछ चेतावनी हो सकती है!)

पुनश्च। यह उत्तर बताता है कि आपके पास आपके git रिपॉजिटरी की रिमोट कॉपी कहीं है (जैसे GitHub पर) और टूटी हुई रिपॉजिटरी स्थानीय रिपॉजिटरी है जो रिमोट रिपॉजिटरी से जुड़ी है जो अभी भी चातुर्य में है। अगर ऐसा नहीं है, तो इसे मेरे द्वारा सुझाए गए तरीके से ठीक करने का प्रयास न करें।

— मार्टिन ताजूर
स्रोत
इसके लिए धन्यवाद, मैं धार्मिक रूप से अपनी दूरस्थ शाखाओं को धक्का देता हूं और आपके समाधान ने मेरे लिए काम किया। मैंने पहले @ mCorr के नीचे की कोशिश की, लेकिन बाद में जब मैंने नई फाइल की तो रेपो वापस भ्रष्ट हो गया। इस दृष्टिकोण ने इसे हल किया
— mr_than
अधिकांश के पास एक रिमोट है। यह समाधान वास्तव में स्वच्छ और पर्याप्त है।
— जैकऑफऑल
7
एक वीएम को बंद करने के बाद यह समस्या थी जिसमें मैं एक गिट रेपो के साथ काम कर रहा था। यह समाधान पूरी तरह से काम करता है।
— गिसकार्ड बायम्बी
धन्यवाद मार्टिन, उत्कृष्ट और कॉम्पैक्ट समाधान। हालाँकि मैं उस पीएस को सबसे पहले रख सकता हूं, जिसमें बोल्ड चेतावनी के साथ भोले-भाले यूजर्स को रोकने की कोशिश की जा रही है। Giscard की तरह, VM को बंद करने पर यह मेरे लिए उत्पन्न होता है ... यदि मैं हर बार ऐसा करने से अधिक स्थायी समाधान ढूंढता हूं, तो वह अपडेट हो जाएगा।
— १०:१०
2
एक वीएम क्रश ने मेरे स्थानीय गिट रेपो
— असवेल के
35

यह त्रुटि मुझे तब होती है जब मैं अपनी प्रतिबद्धता को आगे बढ़ाता हूं और मेरा कंप्यूटर हैंग हो जाता है। मैंने इसे ठीक कर लिया है।

ठीक करने के उपाय

git status

खाली / भ्रष्ट वस्तु फ़ाइल दिखाएं

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

इसे हटा दो

git status

मुझे fatal: bad object HEADसंदेश मिला

rm .git/index

मैं indexरीसेट के लिए निकालता हूं

git reset

घातक: 'HEAD' ऑब्जेक्ट को पार्स नहीं कर सकता।

git status
git pull

बस क्या हो रहा है की जाँच करने के लिए

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

tail -n 2मेरा अंतिम 2 दिखाने के लिए लॉग ब्रांच की अंतिम 2 पंक्तियों को प्रिंट करता हैcommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

मैं आखिरी चुनता हूं commit hash

git status

सभी के रूप में मेरी फाइल से पता चलता deletedक्योंकि मैं हटा दिया .git/indexफ़ाइल

git reset

रीसेट करने के लिए जारी रखें

git status

मेरा फिक्स सत्यापित करें

नोट: चरण तब शुरू होते हैं जब मैं इस सवाल पर उतरा और संदर्भ के रूप में उत्तर का उपयोग किया।

— Marlo
स्रोत
34

मैंने इसे विभिन्न खाली फाइलों को हटाकर हल किया जो गिट फस्क का पता लगा रहे थे, और फिर एक सरल गिट पुल को चला रहे थे।

मुझे यह निराशाजनक लगता है कि अब जब फाइलसिस्टम भी जर्नलिंग और अन्य "ट्रांसेक्शनल" तकनीकों को लागू करते हैं, तो एफएस को सेंस रखने के लिए, गिट एक भ्रष्ट स्थिति (और खुद से उबरने में सक्षम नहीं) डिवाइस पर बिजली की विफलता या अंतरिक्ष के कारण हो सकता है।

— सिमोन गियानी
स्रोत
3
मुझे यकीन है कि उपरोक्त उत्तर तकनीकी रूप से बेहतर है, लेकिन इसने चरण 6 पर काम करना बंद कर दिया और तकनीकी रूप से मेरे सिर के ऊपर था। समीचीन दृष्टिकोण गिट पुल
— mblackwell8
2
मुझे एक ऐसी स्थिति का सामना करना पड़ा, जहाँ नथन के जवाब से निर्देशों के 1-11 कदम (जो बहुत काम आया!) के बाद, मुझे एक त्रुटि हुई जो कह रही थी कि refs / origin / master और refs / Origin / head को परिभाषित नहीं किया गया था (या ऐसा कुछ उस)। गिट पुल कि तय की। इसलिए मुझे लगता है कि दोनों समाधान एक साथ काम करते हैं।
— bchurchill
2
मुझे पता है कि आमतौर पर उपयोग किए जाने वाले फाइलसिस्टम केवल मेटा-डेटा को प्रकाशित करते हैं। आप डेटा के लिए भी जर्नलिंग चालू कर सकते हैं, लेकिन मुझे लगता है कि ओवरहेड (?) के कारण इसकी डिफ़ॉल्ट नहीं है कि शायद फाइलें खाली थीं .... और फाइल सिस्टम आमतौर पर प्रति फ़ाइल लेनदेन का निरीक्षण करते हैं, जबकि गिट में कई फाइलें संशोधित की जा रही हैं। प्रति ट्रांजेक्शन, इस प्रकार भले ही fs प्रति फ़ाइल में निरंतरता रखता हो, अगर git नहीं करता है, तो मुझे लगता है कि git असंगत
— अवस्था
इस जवाब ने मेरे लिए काम किया, अन्य लोग जटिल हैं।
— ldog
1
स्वीकृत उत्तर की तुलना में तेज़ समाधान। उन सभी लोगों के लिए, जिन्होंने अब तक स्क्रॉल किया है, यदि आप जल्दी में हैं तो इस उत्तर का पालन करें।
— श्री हर्ष कपाल
9

मेरे पास बस एक ही मुद्दा था: दूर के भंडार को खींचने के बाद, जब मैंने एक गिट का दर्जा किया तो मुझे मिला: "त्रुटि: ऑब्जेक्ट फ़ाइल (...) खाली है" "घातक: ढीली वस्तु (...) दूषित है"

जिस तरह से मैंने इसे हल किया वह था:

  1. जीआईटी की मार
  2. त्रुटि में git फ़ाइल को हटाना (सुनिश्चित नहीं है कि आवश्यक है)
  3. git stash स्पष्ट

मुझे नहीं पता कि वास्तव में क्या हुआ था, लेकिन यह निर्देश सब कुछ साफ करने के लिए लग रहा था।

— निकोलस
स्रोत
2
मुझे हमेशा सरल उत्तर पसंद हैं :) चरण 2 के लिए यहां मैंने @Nathan VanHoudnos के उत्तर में दिए गए कमांड का उपयोग किया:cd .git/ && find . -type f -empty -delete
— mopo922
8

क्योंकि मुझे अपने वीएम को नियमित रूप से रिबूट करना पड़ता है, इसलिए किसी तरह यह समस्या मेरे साथ बहुत बार होती है। इसके कुछ समय बाद, मुझे एहसास हुआ कि मैं हर बार ऐसा होने पर @ नाथन-वनहुडनोस द्वारा वर्णित प्रक्रिया को नहीं दोहरा सकता, हालांकि यह हमेशा काम करता है। फिर मैंने निम्नलिखित तेजी से समाधान निकाला।

चरण 1

अपने पूरे रेपो को दूसरे फ़ोल्डर में ले जाएं।

mv current_repo temp_repo

चरण 2

रेपो को फिर से मूल से क्लोन करें।

git clone source_to_current_repo.git

चरण 3

.It फ़ोल्डर को छोड़कर नए रेपो के तहत सब कुछ निकालें ।

चरण 4

ले जाएँ सब कुछ से temp_repo नई रेपो को छोड़कर .git फ़ोल्डर।

चरण 5

Temp_repo निकालें , और हम कर रहे हैं।

कुछ समय बाद, मुझे यकीन है कि आप इस प्रक्रिया को बहुत जल्दी कर सकते हैं।

— HaoQiang
स्रोत
2
या अपने वर्तमान रेपो को स्थानांतरित न करें, 1) एक नया क्लोन बनाएं git clone source_to_current_repo.git clean_repo, 2। पुराने .it फोल्डर का बैकअप लें, 3। क्लीन के ऊपर। फोल्डर पर।
— moi
तुम सही हो। मैंने पहले ही कर दिया था। उत्तर को बाद में संपादित करेंगे।
— हॉकियांग
@haoqiang: आपने लिखा है "क्योंकि मुझे अपने वीएम को नियमित रूप से रिबूट करना पड़ता है, इसलिए किसी तरह यह समस्या मेरे साथ बहुत बार होती है।" हम वही अनुभव करते हैं। क्या आपने मूल कारण पर कोई प्रगति की है - वीएम सेटिंग्स जो समस्या को कम करती है?
— हंसन
6
  1. बैकअप लेने के लिए अपने फ़ोल्डर ऐप को mv करें, यानी mv app_folder app_folder_bk (यह एक gash stash की तरह है )
  2. git क्लोन your_repository
  3. आखिरकार,। एक मर्ज टूल खोलें (मैं मेल्ड डिफ व्यूअर लाइनक्स या विंमर्ज विंडोज का उपयोग करता हूं) और दाएं ( app_folder_bk ) से लेफ्ट (नए app_folder ) में बदलावों को कॉपी करता हूं (यह एक git stash apply की तरह है )।

बस इतना ही। शायद यह सबसे अच्छा तरीका नहीं है, लेकिन मुझे लगता है कि यह बहुत व्यावहारिक है।

— cyberfranco
स्रोत
1
जब आप सभी स्थानीय परिवर्तनों को एक अपस्ट्रीम पर धकेल देते हैं, या परिवर्तन न्यूनतम होते हैं, तो आपको ऐसा करना चाहिए, इसलिए क्लोनिंग रिकवरी की तुलना में तेज़ है।
— म्यू m
3

मेरे मामले में, यह त्रुटि इसलिए हुई क्योंकि मैं प्रतिबद्ध संदेश टाइप कर रहा था और मेरी नोटबुक बंद हो गई थी।

त्रुटि को ठीक करने के लिए मैंने ये कदम उठाए:

  • git checkout -b backup-branch # एक बैकअप शाखा बनाएं
  • git reset --hard HEAD~4# उस कमिट पर रीसेट करें जहां सब कुछ अच्छा काम करता है। मेरे मामले में, मुझे सिर में 4 कमिट्स वापस करने थे, जब तक कि मैं प्रतिबद्ध संदेश टाइप नहीं कर रहा था, तब तक मेरा सिर इस बिंदु पर रहेगा। इस चरण को करने से पहले, आपके द्वारा रीसेट किए गए कमिट के हैश की प्रतिलिपि बनाएँ, मेरे मामले में मैंने 4 अंतिम हिट के हैश की प्रतिलिपि बनाई
  • git cherry-pick <commit-hash> # चेरी ने रीसेट किए गए कमिट्स को चुना (मेरे मामले में 4 कमिट हैं, इसलिए मैंने पुरानी शाखा से नई शाखा में यह कदम 4 बार किया)।
  • git push origin backup-branch # यह सुनिश्चित करने के लिए नई शाखा को पुश करें कि सब कुछ अच्छी तरह से काम करता है
  • git branch -D your-branch # स्थानीय रूप से शाखा को हटाएं ('आपकी शाखा' समस्या वाली शाखा है)
  • git push origin :your-branch # शाखा को रिमोट से हटाएं
  • git branch -m backup-branch your-branch # जिस शाखा में समस्या थी उसका नाम रखने के लिए बैकअप शाखा का नाम बदलें
  • git push origin your-branch # नई शाखा को पुश करें
  • git push origin :backup-branch # बैकअप शाखा को रिमोट से हटाएं
— androidevil
स्रोत
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

मेरी समस्या का समाधान करो

— गुई-यी
स्रोत
इससे मदद मिली। धन्यवाद।
— स्वेटेक
यदि रेपो साफ है, तो आपको बस "cd .it / && ढूँढें git status।
— कोडिचन
2

इस समस्या से निपटने के लिए यहां एक बहुत ही सरल और त्वरित तरीका है यदि आपके पास सभी शाखाओं के साथ एक स्थानीय रेपो है और आपकी ज़रूरत है, और यदि आप एक नया रेपो बनाने (या सर्वर के रेपो को हटाने और एक नया बनाने के साथ ठीक हैं) इसकी जगह पर):

  1. सर्वर पर एक नया खाली रेपो बनाएं (या पुराने रेपो को हटा दें और उसकी जगह एक नया बनाएं)
  2. नए रेपो के दूरस्थ URL को इंगित करने के लिए अपनी स्थानीय प्रतिलिपि के दूरस्थ URL को बदलें।
  3. अपने स्थानीय रेपो से लेकर नए सर्वर रेपो तक सभी शाखाओं को पुश करें।

यह उन सभी प्रतिबद्ध इतिहास और शाखाओं को सुरक्षित रखता है जो आपके स्थानीय रेपो में थीं।

यदि आपके पास रेपो पर सहयोगी हैं, तो मुझे लगता है कि कई मामलों में आपके सभी सहयोगियों को अपने स्थानीय रेपो के दूरस्थ URL को भी बदलना होगा, और वैकल्पिक रूप से उनके पास कोई भी कमिट धक्का होगा जो सर्वर के पास नहीं है।

यह समाधान मेरे लिए तब काम आया जब मैं इसी समस्या में भाग गया। मेरा एक सहयोगी था। जब मैंने अपने स्थानीय रेपो को नए रिमोट रेपो में धकेल दिया, तो उसने बस रिमोट रेपो URL और सब कुछ ठीक होने के लिए अपने स्थानीय रेपो को बदल दिया।

— डेविड फ्रेंच
स्रोत
2

मैं मान रहा हूं कि आपके पास पहले से धकेल दिए गए सभी प्रासंगिक परिवर्तनों के साथ एक रिमोट है। मैंने स्थानीय परिवर्तनों की परवाह नहीं की और केवल एक बड़े भंडार को हटाने और पुनर्विचार से बचना चाहता था। यदि आपके पास महत्वपूर्ण स्थानीय परिवर्तन हैं तो आप अधिक सावधान रहना चाहते हैं।

मेरे लैपटॉप के दुर्घटनाग्रस्त होने के बाद भी मुझे यही समस्या थी। संभवतः क्योंकि यह एक बड़ी रिपॉजिटरी थी, जिसमें मेरे पास कुछ भ्रष्ट ऑब्जेक्ट फाइलें थीं, जो कॉल करते समय केवल एक बार दिखाई देती थीं git fsck --full, इसलिए मैंने उनमें से एक को स्वचालित रूप से हटाने के लिए एक छोटा शेल वन-लाइनर लिखा:

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

  • 2>&1 त्रुटि संदेश को पुन: प्रेषित करने में सक्षम होने के लिए उसे अनुप्रेषित करता है
  • grep विकल्प का उपयोग किया जाता है:
    • -o केवल एक पंक्ति का हिस्सा देता है जो वास्तव में मेल खाता है
    • -E उन्नत रीगेक्स को सक्षम करता है
    • -m 1 सुनिश्चित करें कि केवल पहला मैच ही लौटा है
    • [0-9a-f]{2} 0 और 9 और a और f के बीच के किसी भी अक्षर से मेल खाता है यदि उनमें से दो एक साथ होते हैं
    • [0-9a-f]* 0 और 9 के बीच के वर्णों की किसी भी संख्या से मेल खाता है और एक साथ f और f हो रहा है

यह अभी भी एक बार में केवल एक फ़ाइल को हटाता है, इसलिए आप इसे लूप में कॉल करना चाहते हैं:

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

इसके साथ समस्या यह है, कि यह अब उपयोगी कुछ भी आउटपुट नहीं करता है, इसलिए आपको पता नहीं है कि यह कब समाप्त हो जाता है (इसे कुछ समय बाद उपयोगी कुछ भी नहीं करना चाहिए)

इसे "ठीक" करने के लिए मैंने तब git fsck --fullप्रत्येक राउंड के बाद एक कॉल जोड़ा जैसे: $ 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

यह अब लगभग आधा उपवास कर रहा है, लेकिन यह उत्पादन "राज्य" करता है।

इसके बाद मैंने इस थ्रेड में सुझावों के साथ कुछ के आसपास खेला और अंत में एक बिंदु पर पहुंच गया, जहां मैं git stashऔर git stash dropबहुत सारे टूटे हुए सामान रख सकता था।

पहली समस्या हल हुई

बाद में मुझे अभी भी निम्नलिखित समस्या थी: unable to resolve reference 'refs/remotes/origin/$branch': reference brokenजिसे हल किया जा सकता था $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

मैंने तब ए $ git gc --prune=now

$ git remote prune origin

अच्छे उपाय के लिए और

git reflog expire --stale-fix --all

error: HEAD: invalid reflog entry $blubbजब दौड़ने से छुटकारा पाने के लिए git fsck --full।

— memo42
स्रोत
2

चलो सरल चलते हैं .. केवल मामला जिसे आपने रिमोट गिट रेपो में स्रोत अपलोड किया है

  1. बैकअप अपने .git

  2. अपने git की जाँच करें

    git fsck --full

  3. खाली ऑब्जेक्ट फ़ाइल (सभी) निकालें

    rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e

  4. अपने git को फिर से जांचें।

    git fsck --full

  5. दूरस्थ गिट से अपने स्रोत को खींचो

    git pull origin master
— AXT.SIREN
स्रोत
2

मैं आभासी मशीनों के साथ इस समस्या में बहुत भागता हूं।

मेरे लिए निम्नलिखित कार्य हैं:

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

यदि आप अपने आप को कुछ डाउनलोड सहेजना चाहते हैं - अपनी फ़ाइल एक्सप्लोरर में जाएं और पहले से ही प्रतिबद्ध फ़ोल्डर में सभी फाइलों को हटा दें और अपने / विक्रेता और / नोड_मॉड्यूल (मैं संगीतकार और एनपीएम के साथ काम करता हूं) फ़ोल्डर में छोड़ दूं।

तो बस एक नया रेपो बनाएँ

git init

अपना रिमोट जोड़ें

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

और इसकी सभी शाखाएँ प्राप्त करें

git fetch origin somebranch

और इसे देखें

git checkout somebranch

तो आप त्रुटि से पहले बिंदु पर होना चाहिए।

उम्मीद है की यह मदद करेगा।

सादर।

— germanyDevelops
स्रोत
1

मैं एक ही समस्या का सामना करता हूं, और मैं इसे ठीक करने के लिए बहुत ही सरल तरीके का उपयोग करता हूं। मैंने पाया कि वे गायब फाइलें मेरे साथी के कंप्यूटर पर मौजूद थीं।

मैंने उन फ़ाइलों को एक-एक करके जीआईटी सर्वर (कुल 9 फाइलें) में कॉपी किया और उस समस्या को ठीक कर दिया।

— qiucw
स्रोत
1

मेरे सहयोगियों और मैं इसी समस्या के साथ कई बार पार कर चुके हैं और इसे हल करने के लिए हम बस उन चरणों को करते हैं जिनका मैं नीचे वर्णन करता हूं। यह सबसे सुरुचिपूर्ण समाधान नहीं है जो पाया जा सकता है लेकिन यह डेटा के नुकसान के बिना काम करता है।

  1. वर्तमान कार्य निर्देशिका का नाम बदलें। ( old_projectइस उदाहरण के लिए)।
  2. का उपयोग कर एक नई निर्देशिका के भीतर भंडार क्लोन git clone।
  3. कमांड लाइन पर, नई बनाई गई परियोजना के लिए कार्यशील निर्देशिका को बदलें और उस शाखा पर स्विच करें जिस पर आप काम कर रहे हैं।
  4. सभी फ़ाइलों और निर्देशिकाओं की प्रतिलिपि बनाएँ old_project ( को छोड़कर .git) को नई बनाई गई परियोजना निर्देशिका में ।
  5. अपनी कार्यशील स्थिति की जाँच करें (ध्यान दें कि आपकी अपेक्षा से कई अधिक परिवर्तन हैं) और फिर परिवर्तन करें।

मुझे उम्मीद है यह मदद करेगा...

— ymiraola
स्रोत
1

यहाँ समस्या को हल करने का एक तरीका है अगर github.com पर आपका सार्वजनिक रेपो काम कर रहा है, लेकिन आपका स्थानीय रेपो भ्रष्ट है। ध्यान रखें कि आप स्थानीय रीपो में किए गए सभी कमिट्स को ढीला कर देंगे।

ठीक है, इसलिए मेरे पास स्थानीय रूप से एक रेपो है जो मुझे यह दे रहा है object empty error , और github.com पर भी यही रेपो है, लेकिन इस त्रुटि के बिना। इसलिए मैंने जो कुछ भी किया, वह था रीथो को क्लोन करना जो कि गितुब से काम कर रहा है, और फिर भ्रष्ट रिपॉजिट (.गित फ़ोल्डर को छोड़कर) से सब कुछ कॉपी किया, और जो काम कर रहा है उसे क्लोन रेपो पेस्ट कर दिया।

यह एक व्यावहारिक समाधान नहीं हो सकता है (चूंकि आप स्थानीय आवागमन हटाते हैं), हालांकि, आप कोड और मरम्मत किए गए संस्करण को नियंत्रित करते हैं।

इस दृष्टिकोण को लागू करने से पहले बैक-अप याद रखें।

— कोड यथार्थवादी
स्रोत
1

मेरे मामले में, स्थानीय प्रतिबद्ध इतिहास रखना मेरे लिए महत्वपूर्ण नहीं था। तो अगर यह भी आप पर लागू होता है, तो आप इसे ऊपर के समाधान के लिए एक त्वरित विकल्प के रूप में कर सकते हैं:

आप मूल रूप से सिर्फ भ्रष्टों का स्थान लेते हैं .git/ निर्देशिका को केवल एक साफ के साथ ।

दूषित git के साथ आपकी परियोजना के लिए निम्नलिखित निर्देशिका मानें: projects/corrupt_git/

  1. cp projects/corrupt_git projects/backup - (वैकल्पिक) एक बैकअप बनाते हैं
  2. git clone [repo URL] projects/clean_git - ताकि आप प्राप्त करें projects/clean_git
  3. rm -rf corrupt_git/.git/ - दूषित .git फ़ोल्डर को निकालें
  4. mv clean_git/.git/ corrupt_git/ - साफ साफ करने के लिए कदम corrupt_git/.git
  5. git statusमें projects/corrupt_git- यह सुनिश्चित करने के लिए कि यह काम करता है
— बेंजामिन बासमासी
स्रोत
0

बैकअप के लिए सब कुछ (.गित युक्त फ़ोल्डर में) कॉपी करें, फिर सब कुछ हटा दें और पुनरारंभ करें। सुनिश्चित करें कि आपके पास git रिमोट काम है:

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

फिर

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

फिर किसी भी नई फ़ाइल को मैन्युअल रूप से मर्ज करें, और अपने कंप्यूटर को चालू रखने का प्रयास करें।

— Shelvacu
स्रोत
rm -rf * के बहुत बुरे परिणाम हो सकते हैं। क्या आपका वास्तव में मतलब था?
— tommyk
@tommyk इसलिए बैकअप की प्रति पहले। मुझे लगता है कि बल आवश्यक नहीं है।
— शेल्वैकू
0

एक साफ शाखा से मास्टर की जाँच के बाद एक ही समस्या थी। थोड़ी देर के बाद मैंने मास्टर में बहुत सारी संशोधित फाइलों को पहचान लिया। मुझे नहीं पता कि एक साफ शाखा से स्विच करने के बाद वे वहां क्यों गए हैं। वैसे भी, क्योंकि संशोधित फ़ाइलों ने मेरे लिए कोई मतलब नहीं बनाया, मैंने सिर्फ उन्हें मारा और त्रुटि चली गई।

git:(master) git stash

— ownking
स्रोत
0

यदि आपके पास एक OLD बैकअप है और जल्दी में है:

अपने वर्तमान, गिट-टूट, परियोजना पथ का एक नया बैकअप बनाएं।

  1. अपने .gitकूड़ेदान में ले जाएँ (कभी नष्ट न करें)
  2. .gitOLD बैकअप से कॉपी करें
  3. git pull (मर्ज टकराव पैदा करेगा)
  4. अपने सभी स्रोतों को स्थानांतरित करें (सब कुछ जिसे आप गिट में डालते हैं) को रद्दी में डालें: ./src (कभी हटाएं नहीं)
  5. नई बेकअप से अपने सभी स्रोतों (सब कुछ आप जो गिट में डालते हैं) को कॉपी करें
  6. सभी "मर्ज" को स्वीकार करें git gui, धक्का दें और ... अपने हाथों को ताली बजाएं!
— कुंभ शक्ति
स्रोत
0

ऊपर दिए गए बारह कदम के समाधान ने मुझे जाम से बाहर निकालने में मदद की। धन्यवाद। दर्ज करने के लिए महत्वपूर्ण कदम थे:

git fsck --full

और सभी खाली वस्तुओं को हटा दें

rm .git/objects/...

फिर कोहरे की दो पंक्तियाँ प्राप्त करना: 

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

लौटे मूल्यों के साथ

git update-ref HEAD ...

इस बिंदु पर मेरे पास कोई और त्रुटि नहीं थी, इसलिए मैंने अपनी सबसे हाल की फ़ाइलों का बैकअप बनाया। फिर एक गिट पुश द्वारा पीछा किया। मेरे बैकअप को मेरी git रिपॉजिटरी फ़ाइल में कॉपी किया और एक और git पुश किया। जो मुझे करंट लगा।

— याकूब
स्रोत
0

मैंने अपनी git त्रुटि ठीक की: ऑब्जेक्ट फ़ाइल इसके द्वारा खाली है:

  1. मेरी पिछली सफल कमिट / पुश के बाद से संपादित की गई सभी फाइलों की एक कॉपी सेव करना,
  2. मेरी रिपॉजिटरी को हटाना और पुन: क्लोनिंग करना,
  3. मेरी संपादित फ़ाइलों के साथ पुरानी फ़ाइलों को बदलना।

आशा है कि यह मदद करता है।

— JattCode113
स्रोत
0

यह भी मेरे साथ लगभग नियमित रूप से होता है। जब यह वास्तव में होता है तो एक प्रोटोकॉल नहीं बनाया जाता है, लेकिन मुझे संदेह है कि यह तब होता है जब भी मेरी आभासी मशीन "अप्रत्याशित रूप से" मौजूद होती है। अगर मैं VM विंडो बंद करता हूं (मैं Ubuntu 18.04 का उपयोग कर रहा हूं) और फिर से शुरू करता हूं, चीजें हमेशा (?) काम करती हैं। लेकिन अगर मेरा लैपटॉप बंद होने पर (विंडोज़ होस्ट सिस्टम) वीएम विंडो अभी भी खुली है, तो मैं इस समस्या का अक्सर सामना करता हूं।

यहाँ दिए गए सभी उत्तरों के अनुसार:

  1. धन्यवाद - वे बहुत उपयोगी हैं; मैं आमतौर पर अपने कोड की एक स्थानीय प्रतिलिपि सहेजता हूं, रेपो को रिमोट से पुनर्स्थापित करता हूं, और बैकअप प्रतिलिपि को स्थानीय फ़ोल्डर में वापस ले जाता हूं।

  2. जैसा कि अंतर्निहित समस्या वास्तव में एक git मुद्दा नहीं है, बल्कि एक VM और / या लिनक्स समस्या है, मुझे आश्चर्य है कि क्या कारण के बजाय लक्षणों को ठीक करने का कोई तरीका नहीं होना चाहिए? क्या इस तरह की त्रुटि इंगित नहीं करती है कि कुछ फ़ाइल सिस्टम परिवर्तन किसी भी उचित समय में "लागू नहीं" हैं, लेकिन केवल कैश किया गया है? (उदाहरण के लिए देखें /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - मेरे लिए यह ऐसा प्रतीत होता है जैसे वर्चुअल लिनक्स मशीनें नहीं हैं fsynch उनके सामान अक्सर पर्याप्त है। चाहे यह ओरेकल के वर्चुअलबॉक्स का मुद्दा है (जो अन्यथा बहुत अच्छी तरह से काम करता है) या अतिथि फाइल सिस्टम का, या कुछ सेटिंग्स का, जिसे हम सभी अनदेखा करते हैं, मेरी विशेषज्ञता से परे है। लेकिन मुझे खुशी होगी अगर कोई इस पर प्रकाश डाल सके।

— maschu
स्रोत
0

दरअसल मुझे भी यही समस्या थी। इसे आज़माने से पहले अपने कोड की एक कॉपी रखें।

मैंने अभी किया git reset HEAD~

मेरी आखिरी प्रतिबद्धता पूर्ववत थी फिर मैंने इसे फिर से शुरू किया, समस्या हल हो गई!

— k441i
स्रोत
-5

चेतावनी: अधिक अनुभव के साथ, मुझे पता है कि यह परमाणु विकल्प है और आमतौर पर ऐसा नहीं किया जाना चाहिए और कुछ भी नहीं सिखाता है। हालांकि, व्यक्तिगत परियोजनाओं के लिए दुर्लभ अवसरों पर, मैंने अभी भी इसे उपयोगी पाया है, इसलिए मैं इसे छोड़ रहा हूं।

यदि आप अपने ऐतिहासिक कामों को रखने की परवाह नहीं करते हैं, तो बस दौड़ें

rm -r .गित

फिर लिखने-संरक्षित फ़ाइलों को हटाने के बारे में पूछने वाले किसी भी चीज़ के लिए हां में जवाब दें। एक मिनट के अंदर समस्या हल हो गई।

— वास्तव में
स्रोत
3
यदि आप अपना इतिहास चातुर्य में चाहते हैं तो ऐसा न करें।
— म्यू m
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.