बड़ी फाइल के कारण GitHub को धक्का नहीं दे सकता जिसे मैंने पहले ही हटा दिया था

Question

वर्तमान में मेरे पास है

1. गितहब रेपो खाली करो
2. SSH सर्वर रेपो (मुख्य)
3. स्थानीय रेपो

SSH सर्वर रेपो सबसे अद्यतित रेपो (उत्पादन स्थल) था, इसलिए मैंने वहां से स्थानीय के लिए एक Git क्लोन किया। मैं तो git pushGitHub करने के लिए एक करने की कोशिश की ।

सब कुछ ठीक रहा लेकिन फिर उसने फ़ाइलनाम के बारे में कुछ कहा। जीज़हब के लिए बहुत बड़ा होना। मुझे इस फ़ाइल की आवश्यकता नहीं थी इसलिए मैंने इसे Git कैश से निकालने के लिए कई Git कमांड चलाए और फिर SSH सर्वर पर वापस धकेल दिया।

मैं बड़ी फ़ाइल को स्थानीय रूप से नहीं देखता, लेकिन यह अभी भी SSH सर्वर पर है, भले ही git diffकुछ भी न लौटाए और पुश पुश रिटर्न "सब कुछ अप-टू-डेट है" - और भले ही जब मैं धक्का देने की कोशिश करूँ तो फ़ाइल स्थानीय रेपो में दिखाई न दे। GitHub मैं अभी भी इसके बारे में त्रुटि प्राप्त करता हूं

रिमोट: त्रुटि: फ़ाइल fpss.tar.gz 135.17 एमबी है; यह GitHub की फ़ाइल का आकार 100 एमबी से अधिक है

मैंने GitHub की मदद से सूचीबद्ध "समस्या को ठीक करने" के तहत कदमों का पालन किया ताकि यह पर्याप्त न हो?

जब यह स्थानीय या गिट स्थिति / सूचीबद्ध / पुश में सूचीबद्ध नहीं है, तो फ़ाइल अभी भी ईथर में कैसे है?

Comments

फ़ाइल अब भी इतिहास में है। आपको इतिहास को नष्ट करने की आवश्यकता है, संभवतः फ़ाइल को जोड़ने और हटाने वाले कमिट्स को स्क्वाश करके।

— शहबाज

@ शहबाज मैंने इस साइट पर सूचीबद्ध "समस्या को ठीक करने" के तहत कदमों का पालन किया ... क्या यह पर्याप्त नहीं होना चाहिए था? help.github.com/articles/working-with-large-files

— केविन डब्ल्यू।

कमांड वहाँ मेरे ज्ञान के ज्ञान से अधिक उन्नत है, इसलिए मैं वास्तव में नहीं बता सकता। वैसे भी, अगर git log -- the_big_fileआप कुछ भी वापस कर रहे हैं, तो फ़ाइल अभी भी इतिहास में है।

— शहबाज

@ शहबाज जो नॉटिंग्स लौटाते हैं> <

— केविन डब्ल्यू।

क्या ऐसा हो सकता है कि आप अन्य शाखाओं पर भी जोर दे रहे हों जहां फ़ाइल मौजूद है? इसके अलावा, यदि फ़ाइल अभी भी सर्वर पर है, तो git pushसब कुछ अप-टू-डेट क्यों कहेगा? चूंकि आपने इतिहास को बदल दिया है, इसलिए यह शिकायत करनी चाहिए कि धक्का संभव नहीं है और आपको इसे मजबूर करना होगा।

— शाहबाज

Answer 1

आप उपयोग कर सकते हैं

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD

यह उस फ़ाइल के इतिहास में सब कुछ हटा देगा। समस्या यह है कि फ़ाइल इतिहास में मौजूद है।

यह कमांड आपके कमिट के हैश को बदल देता है जो एक वास्तविक समस्या हो सकती है, विशेष रूप से साझा रिपॉजिटरी पर। इसके परिणामों को समझे बिना प्रदर्शन नहीं किया जाना चाहिए।

Comments

मेरे लिए काम किया, लेकिन मुझे इसे 'मजबूर' करना पड़ा: git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file / dir>' -f HEAD

— alexoviedoat

यह कमांड आपके कमिट के हैश को बदल देता है जो एक वास्तविक समस्या हो सकती है, विशेष रूप से साझा रिपॉजिटरी पर। इसके परिणामों को समझे बिना प्रदर्शन नहीं किया जाना चाहिए।

— क्रिस

क्या आप फ़ाइल के नाम के साथ <file / dir> को बदलना चाहते हैं या dir जो समस्या पैदा कर रहा है?

— डेविड रोडेन

ध्यान दें कि यदि आप सभी शाखाओं में इन परिवर्तनों को लागू करना चाहते हैं, तो आपको --allइसके बजाय एक ध्वज का उपयोग करने की आवश्यकता हैHEAD

— Nick Spreitzer

मैं हो रही है:Rewrite 657560fa18c030bcfac9132ce1c3541e84a5bc2c (1/10) (0 seconds passed, remaining 0 predicted) /usr/lib/git-core/git-filter-branch: 1: eval: Syntax error: end of file unexpected

— जोआओ एबरेन्तीज़

Answer 2

मैंने पाया कि स्कैशिंग से अधिक उपयोगी है filter-branch। मैंने निम्नलिखित कार्य किया:

1. स्थानीय रूप से बड़ी फ़ाइलों को हटा दें।
2. स्थानीय हटाएं।
3. शीतल रीसेट वापस एक्स की संख्या (मेरे लिए यह 3 था) git reset --soft HEAD~3:।
4. फिर एक साथ सभी परिवर्तनों को पुनः प्राप्त करें (AKA स्क्वैश) git commit -m "New message for the combined commit"
5. धक्का-मुक्की की गई।

विशेष मामला (उपयोगकर्ता @lituo से): यदि ऊपर काम नहीं करता है, तो आपके पास यह मामला हो सकता है। कमिट 1 में बड़ी फ़ाइल शामिल थी और बड़ी फ़ाइल त्रुटि के कारण कमिट का पुश विफल हो गया था। कमिट 2 ने बड़ी फाइल को हटा दियाgit rm --cached [file_name]लेकिन कमिट 2 का पुश अभी भी विफल रहा। आप ऊपर दिए गए समान चरणों का पालन कर सकते हैं, लेकिन उपयोग करने के बजायHEAD~3, उपयोग करेंHEAD~2।

Comments

मेरे लिए काम किया, बस स्क्वैश पुश के काम करने से पहले तीनों बदलावों को अपने स्थानीय भंडार में फिर से मिलाना था।

— दाससेन

यह शीर्ष उत्तर से बेहतर है। शीर्ष उत्तर आपके पूरे प्रतिबद्ध इतिहास पर शिकंजा कसता है।

— manic.coder

मेरी समस्या को ठीक नहीं किया

— Hirak Sarkar

यह अब तक केवल एक ही उत्तर है जो बड़ी अनप्लग या प्रतिबद्ध फ़ाइलों को ठीक करता है, बिना पूरी तरह से रिपॉजिटरी के बिना! इसलिए इसे ऊपर ले जाया जा सकता है :-)

— 13lex

@ लेकिन मैं एक रैपर वर्ग नहीं हूँ: बहुत बहुत धन्यवाद! यह आकर्षण की तरह काम किया :)

— POOJA GUPTA

Answer 3

अगर आपने पहले ही मदद के लिए कह दिया है, तो मुझे कुछ मदद मिली है। पहला प्रकार:

git status

इसके बाद, आपको कुछ लाइनों के साथ देखना चाहिए

On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

महत्वपूर्ण हिस्सा "2 कमिट" है! यहां से, आगे बढ़ें और टाइप करें:

git reset HEAD~<HOWEVER MANY COMMITS YOU WERE BEHIND>

इसलिए, ऊपर दिए गए उदाहरण के लिए, एक टाइप करेगा:

git reset HEAD~2

आपके लिखे जाने के बाद, आपकी "स्थिति" को कहना चाहिए:

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

वहां से, आप बड़ी फ़ाइल को हटा सकते हैं (यह मानते हुए कि आपने पहले से ऐसा नहीं किया है), और आपको अपना काम खोए बिना सब कुछ फिर से करने में सक्षम होना चाहिए।
मुझे पता है कि यह एक सुपर फैंसी जवाब नहीं है, लेकिन मुझे आशा है कि यह मदद करता है!

Comments

विजेता। सरल, साफ, प्रभावी, निर्मित समाधान। प्रेम ऐसे उत्तर देता है।

— रीस डेनियल

यह सबसे अच्छा उपाय है।

— व्रहूल

Answer 4

यदि फ़ाइल को आपकी सबसे हाल की प्रतिबद्ध के साथ जोड़ा गया था , और आपने दूरस्थ रिपॉजिटरी में धक्का नहीं दिया है , तो आप फ़ाइल को हटा सकते हैं और कमिट कर सकते हैं, यहां से लिया जा सकता है :

git rm --cached giant_file
    # Stage "giant_file" for removal with "git rm"
    # Leave it on disk with "--cached". if you want to remove it from disk
    # then ignore the "--cached" parameter
git commit --amend -CHEAD
    # Commit the current tree without the giant file using "git commit"
    # Amend the previous commit with your change "--amend" 
    # (simply making a new commit won't work, as you need
    # to remove the file from the unpushed history as well)
    # Use the log/authorship/timestamp of the last commit (the one we are
    # amending) with "-CHEAD", equivalent to --reuse-message=HEAD
git push
    # Push our rewritten, smaller commit with "git push"

Comments

यह समाधान काम नहीं करेगा क्योंकि फ़ाइल अब git index में नहीं है (यह untrackedफ़ाइल सूची के रूप में परिणाम देता है git status।

— loretoparisi

कुछ नहीं हो रहा है। इसे लागू करने के बाद यह फ़ाइल संख्या की कुल संख्या को कम कर देता है, लेकिन प्रक्रिया दिखाने के बाद 99% फिर से अटक गया। कोई भी सुझाव जो मुझे याद आ रहा है?

— CoDe

क्या मतलब है?

— एरिन

क्या होगा अगर मैं एक विशिष्ट प्रतिबद्ध से यह कोशिश करना चाहता हूं - बहुत आखिरी प्रतिबद्ध नहीं? मैंने कोशिश की, git rm --cached giant_file commit_idलेकिन यह काम नहीं किया :(

— puifais

@ पिनिफ़ाइस मैं पिछली प्रतिबद्धताओं पर लौटूंगा, इन चरणों को करूंगा, और फिर वर्तमान के साथ विलय करूंगा। मुझे यकीन नहीं है कि अगर यह सबसे अच्छा तरीका है, तो मैं Git विशेषज्ञ नहीं हूं

— BlueMoon93

Answer 5

मेरे पास एक समान मुद्दा था और ऊपर दिए गए कदम का इस्तेमाल किया फ़ाइल को निकालने के लिए गए । इसने पूरी तरह से काम किया।

फिर मुझे एक दूसरी फ़ाइल पर एक त्रुटि मिली जिसे मुझे हटाने की आवश्यकता थी: remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB

मैंने एक ही चरण की कोशिश की, एक त्रुटि हुई: "A previous backup already exists in <path/filename>"

इस वेबसाइट पर शोध से मैंने कमांड का उपयोग किया:git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --prune-empty --tag-name-filter cat -- --all

महान काम किया, और बड़ी फ़ाइलों को हटा दिया गया।

अविश्वसनीय रूप से, धक्का अभी भी एक और त्रुटि के साथ विफल रहा: error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly

यह मैंने .it config फाइल को सीधे संशोधित करके तय किया है - postBuffer = 999999999

उसके बाद धक्का-मुक्की हुई!

Comments

एक अतिरिक्त गोचरा मुझे एक बड़ी फ़ाइल (जैसा कि ऊपर) को हटाने के साथ संघर्ष करना था कि एक फ़ोल्डर में एक हैश # वर्ण था। यह सामान्य git ऑपरेशन के लिए बिल्कुल भी कोई समस्या नहीं थी, हालाँकि git rmमुझे फ़ाइल के लिए पूर्ण रिपॉजिटरी पथ का नाम देने की आवश्यकता थी और इसे काम पर लाने के लिए बैकस्लैश के साथ # बचने के लिए

— jacanterbury

यह मेरे लिए भी काम करता है। मैंने reset hardएक सरल धक्का के साथ पृष्ठ के निचले भाग में कदम रखा। czettner.com/2015/07/16/…

— मोंटे

इसने 'गिट पुश

— -फ ओरिजिन

Answer 6

बड़ी फाइल को डिलीट करने के बाद भी GitHub मेरे रेपो को क्यों खारिज कर रहा है?

Git आपके प्रोजेक्ट का पूरा इतिहास संग्रहीत करता है, इसलिए भले ही आप अपनी परियोजना से किसी फ़ाइल को 'डिलीट' कर दें, लेकिन Git repo के पास अभी भी इतिहास की फ़ाइल की एक प्रति है, और यदि आप किसी अन्य रिपॉजिटरी (जैसे एक पर होस्ट किया गया) को पुश करने का प्रयास करते हैं GitHub) के बाद Git को रिमोट रेपो की आवश्यकता होती है जो आपके स्थानीय रेपो करता है (यानी इतिहास में वही बड़ी फाइलें)।

मैं अपने रेपो को स्वीकार करने के लिए GitHub कैसे प्राप्त कर सकता हूं?

आपको अपने प्रोजेक्ट के Git इतिहास को स्थानीय स्तर पर साफ करने की जरूरत है, इतिहास की अवांछित बड़ी फ़ाइलों को हटाकर, और उसके बाद ही आगे जाने वाले 'क्लीन' इतिहास का उपयोग करें। प्रभावित कमिट्स की Git कमिट आईडी बदल जाएगी।

मैं अपने Git रेपो से बड़ी फ़ाइलों को कैसे साफ़ करूँ?

गिट इतिहास से बाहर अवांछित बड़ी फ़ाइलों को साफ करने के लिए सबसे अच्छा उपकरण बीएफजी रेपो-क्लीनर है - यह एक सरल, तेज विकल्प है जो git-filter-branchविशेष रूप से गिट इतिहास से अवांछित फ़ाइलों को हटाने के लिए डिज़ाइन किया गया है।

उपयोग निर्देशों का सावधानीपूर्वक पालन करें , मुख्य भाग बस यही है:

$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git

100 एमबी से अधिक आकार की कोई भी फ़ाइल (जो आपकी नवीनतम कमिट में नहीं हैं) को आपके गिट रिपॉजिटरी के इतिहास से हटा दिया जाएगा। फिर आप git gcमृत डेटा को दूर करने के लिए उपयोग कर सकते हैं :

$ git gc --prune=now --aggressive

बीएफजी आमतौर पर चलने की तुलना में कम से कम 10-50x तेज होता हैgit-filter-branch , और आमतौर पर उपयोग करने में बहुत आसान होता है।

पूर्ण प्रकटीकरण: मैं बीएफजी रेपो-क्लीनर का लेखक हूं।

Comments

मेरे मामले में अतिरिक्त जटिलताएं थीं, जो स्क्वाशिंग को रोकती थीं। BFG टूल ने बहुत अच्छा काम किया। धन्यवाद।

— दन्तोपा

यह एक अभूतपूर्व समाधान है

— यौन संबंध

Answer 7

मुझे वही समस्या मिली और कोई भी जवाब मेरे लिए काम नहीं करता है। मैंने निम्नलिखित चरणों को हल किया है:

1. खोजें कि कौन सी कमिट में बड़ी फाइल है

git log --all -- 'large_file`

नीचे का कमिट सबसे पुराना हैरिजल्ट लिस्ट में ।

2. सबसे पुराने से पहले एक खोजें।

git log

मान लीजिये आपको मिल गया:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. गिट रिबास

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

टिप्स :

1. सामग्री सूचीबद्ध करें
2. मैं सिर्फ dropकमिट के लिए चुनता हूं जिसमें बड़ी फाइल है।
3. आप रिबेट के दौरान संघर्षों को पूरा कर सकते हैं और उन्हें git rebase --continueतब तक इस्तेमाल कर सकते हैं जब तक आप इसे पूरा नहीं करते।
4. अगर git rebase --abortइसे रद्द करने के लिए रिबेस के उपयोग के दौरान कुछ भी गलत हुआ ।

Answer 8

मैंने उपरोक्त सभी तरीकों की कोशिश की है, लेकिन उनमें से कोई भी मेरे लिए काम नहीं करता है।

फिर मैं अपने समाधान के साथ आया।

1. सबसे पहले, आपको स्थानीय रेपो की एक साफ-सुथरी जरूरत है। सभी कमबख्त बड़ी फ़ाइलों को हटा दें।

2. अब अपने रेपो फोल्डर का एक नया फ़ोल्डर OUTSIDE बनाएं और इसे "Git create repository" का उपयोग करके इसे नया Git रिपॉजिटरी बनाने के लिए उपयोग करें, इसे new_local_repo कहते हैं। यह बात है! उपरोक्त सभी विधियों ने कहा कि आपको इतिहास को साफ करना होगा ..., ठीक है, मैं इससे बीमार हूं, चलो एक नया रेपो बनाएं जिसका कोई इतिहास नहीं है!

3. अपने पुराने से फाइलों को कॉपी करें, स्थानीय रेपो को नए, सुंदर रेपो में गड़बड़ करें। ध्यान दें कि फ़ोल्डर आइकन पर हरा लोगो गायब हो जाएगा, यह आशाजनक है क्योंकि यह एक नया रेपो है!

4. स्थानीय शाखा के लिए प्रतिबद्ध है और फिर दूरस्थ नई शाखा को धक्का। चलिए इसे new_remote_branch कहते हैं। यदि आप नहीं जानते कि कैसे एक नए स्थानीय रेपो से धक्का दिया जाए, तो Google

5. बधाई! आपने अपना साफ़-सुथरा अप-टू-डेट कोड GitHub को धकेल दिया है। यदि आपको अब दूरस्थ मास्टर शाखा की आवश्यकता नहीं है, तो आप अपनी new_remote_branch को नई मास्टर शाखा बना सकते हैं। यदि आप नहीं जानते कि यह कैसे करना है, तो Google इसे करें।

6. अंतिम चरण, पुराने गड़बड़ स्थानीय रेपो को हटाने का समय है। भविष्य में आप केवल new_local_repo का उपयोग करते हैं।

Answer 9

git lfs migrate import --include="fpss.tar.gz"

यह आपके स्थानीय कमेंट्स को नए lfs refs के साथ फिर से लिखना चाहिए

https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn?utm_source=gitlfs_site&utm_medium=doc_man_migrate_link&utm_campaign=gitlfs#examples

Answer 10

कार्य फ़ोल्डर के भीतर बड़ी फ़ाइलों / फ़ोल्डरों को रखने का समाधान

यह वह रेखा है जो यहां पूछी गई समस्या को हल करने के लिए काम करती है (उत्तर 1 से):

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD

यदि फ़ाइल / dir कार्यशील ट्री के भीतर है, तो यह कमांड फ़ाइल / dir भी हटाती है।

यदि आप फ़ाइल / फ़ोल्डर को कार्यशील ट्री के भीतर रखना चाहते हैं, तो मैं निम्नलिखित कदम उठाने का प्रस्ताव करता हूं।

1. इसके बाद त्रुटि चलती है git reset HEAD^

2. विचाराधीन फ़ाइल / फ़ोल्डर को `` .gitignore`` फ़ाइल में जोड़ें।

3. सामान्य रूप से आगे बढ़ें git add .जो अन्य फ़ाइलों / फ़ोल्डरों को कैप्चर कर .gitignoreसकता है लेकिन फ़ाइल को कैप्चर करना होगा । अगला है git commit -m"message"और अंत मेंgit push origin <branch_name>

Answer 11

यह मेरे लिए काम किया। Gitub स्क्वाशिंग से प्रलेखन Git Commits git रीसेट मूल / मास्टर

git checkout master && git pull;
git merge feature_branch;
git add . --all;
git commit -m "your commit message"

प्रलेखन यहाँ खोजें

Answer 12

मैं पहले जवाब में जोड़ रहा हूं।

git फ़िल्टर-शाखा --index- फ़िल्टर 'git rm -r - कैशेड -ignore-unmatch' HEAD

मूल / गुरु से कुछ मर्ज संघर्ष होगा।

आपकी शाखा और 'मूल / मास्टर' ने विचलन किया है, और क्रमशः 114 और 109 अलग-अलग कॉमेट्स हैं। (रिमोट शाखा को आप में विलय करने के लिए "गिट पुल" का उपयोग करें)

कृपया इसे चलाएं

git रीसेट - भार उत्पत्ति / गुरु

यह मेरे सभी मंचित और अस्थिर परिवर्तनों को दूर फेंक देगा, मेरी वर्तमान स्थानीय शाखा पर सब कुछ भूल जाएगा और इसे मूल / गुरु के समान ही बना देगा।

Answer 13

इसलिए मुझे एक विशेष स्थिति का सामना करना पड़ा: मैंने गिटलैब से एक रिपॉजिटरी को क्लोन किया, जिसमें 100 एमबी से बड़ी फ़ाइल थी, लेकिन गिट इतिहास में कुछ बिंदु पर हटा दिया गया था। फिर बाद में जब मैंने एक नया गितुब प्राइवेट रेपो जोड़ा और नए रेपो में धकेलने की कोशिश की, तो मुझे बदनाम 'फ़ाइल बहुत बड़ी' त्रुटि मिली। इस बिंदु तक, मुझे अब मूल गिटलैब रेपो तक पहुंच नहीं थी। हालाँकि, मैं अभी भी bfg-repo-cleanerअपनी मशीन पर LOCAL रिपॉजिटरी का उपयोग करके नए निजी github रेपो पर धकेलने में सक्षम था :

$ cd ~
$ curl https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar > bfg.jar
$ cd my-project
$ git gc
$ cd ../
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-project
$ cd my-project
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
$ git remote -v # confirm origin is the remote you want to push to
$ git push origin master

Answer 14

कभी-कभी फ़ाइल को ट्रैकिंग इतिहास में रखा जाता है, निम्न चरणों का प्रयास करें:

1. git commit, यदि आप सूचीबद्ध बड़ी फ़ाइल के साथ मोड बना रहे हैं , तो करें:

2. git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch filename' HEAD। आपको अपने कंसोल में दिखाए गए रिवाइट्स का एक गुच्छा देखना चाहिए जो इसके साथ समाप्त होता है:

   आरएम 'फ़ाइलनाम' और

   अंतिम पंक्ति Ref को फिर से लिखा गया।

हॊ गया।