रीट लिखित गिट रेपो इतिहास के साथ एक विकास टीम अपडेट करें, बड़ी फ़ाइलों को हटाएं

Question

मेरे पास कुछ बहुत बड़ी बाइनरी के साथ एक गिट रेपो है। अब मुझे उनकी आवश्यकता नहीं है, और मुझे पहले की ओर से फाइलों की जांच करने में सक्षम होने की परवाह नहीं है। तो, रेपो आकार को कम करने के लिए, मैं इतिहास से बाइनरी को पूरी तरह से हटाना चाहता हूं।

एक वेब खोज के बाद, मैं निष्कर्ष निकाला है कि मेरे सबसे अच्छे (केवल?) विकल्प का उपयोग करने git-filter-branch है:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip' HEAD 

इस अब तक एक अच्छा दृष्टिकोण की तरह लग रहा है?

जवाब मानना ​​हाँ है, मुझे सामना करने में एक और समस्या है। git manual has this warning:

चेतावनी! पुनर्लेखित इतिहास में सभी वस्तुओं के लिए अलग-अलग ऑब्जेक्ट नाम होंगे और मूल शाखा के साथ अभिसरण नहीं होंगे। आप मूल शाखा के शीर्ष पर पुनर्लेखित शाखा को आसानी से धक्का और वितरित करने में सक्षम नहीं होंगे। यदि आप पूर्ण प्रभावों को नहीं जानते हैं, तो कृपया इस कमांड का उपयोग न करें, और किसी भी तरह से इसका उपयोग करने से बचें, अगर आपकी समस्या को ठीक करने के लिए एक साधारण एकल प्रतिबद्धता पर्याप्त होगी। (प्रकाशित इतिहास को फिर से लिखने के बारे में अधिक जानकारी के लिए Git-रिबेस (1) में "नदी के ऊपर rebase से उबरने" अनुभाग देखें।)

हम अपने सर्वर पर एक दूरस्थ रेपो की है। प्रत्येक डेवलपर इसे धक्का देता है और खींचता है। ऊपर चेतावनी के आधार पर (और git-filter-branch काम करता है की मेरी समझ के आधार पर), मुझे नहीं लगता कि मैं अपनी स्थानीय प्रतिलिपि पर git-filter-branch चलाने में सक्षम हूं और फिर परिवर्तनों को दबा सकता हूं।

तो, मैं अंतरिम रूप से निम्न चरणों के माध्यम से जाने की योजना बना रही है:

1. मेरे सभी डेवलपर्स को बताएँ प्रतिबद्ध, धक्का, और एक बिट के लिए काम करना बंद कर।
2. सर्वर में लॉग इन करें और केंद्रीय रिपो पर फ़िल्टर चलाएं।
3. क्या हर कोई अपनी पुरानी प्रतियां हटा देता है और सर्वर से क्लोन फिर से हटा देता है।

क्या यह ध्वनि सही है? क्या यह सबसे अच्छा समाधान है?

Answer 1

हां, आपका समाधान काम करेगा। आपके पास दूसरा विकल्प भी है: केंद्रीय रेपो पर ऐसा करने के बजाय, अपने क्लोन पर फ़िल्टर चलाएं और फिर उसे git push --force --all के साथ वापस दबाएं। यह सर्वर को आपके भंडार से नई शाखाओं को स्वीकार करने के लिए मजबूर करेगा। यह केवल चरण 2 की जगह लेता है; अन्य कदम वही होंगे।

यदि आपके डेवलपर सुंदर गिट-समझदार हैं, तो उन्हें अपनी पुरानी प्रतियां हटाना पड़ेगा; उदाहरण के लिए, वे नए रिमोट ला सकते हैं और उचित रूप से अपनी विषय शाखाओं को पुन: प्राप्त कर सकते हैं।

Answer 2

यदि आप अपने डेवलपर्स को फिर से क्लोन नहीं करते हैं तो संभव है कि वे बड़ी फ़ाइलों को वापस खींच सकें। उदाहरण के लिए, यदि वे ध्यान से नए इतिहास पर विभाजित होते हैं तो आप बनायेंगे और फिर git merge से स्थानीय परियोजना शाखा जिसे पुनर्जीवित नहीं किया गया था, विलय प्रतिबद्धता के माता-पिता में परियोजना शाखा शामिल होगी जो आखिरकार पूरे इतिहास में इंगित करती है जिसे आपने git filter-branch से मिटा दिया था।

Answer 3

आपकी योजना अच्छी है (हालांकि केंद्रीय सर्वर की बजाय आपके भंडार के नंगे क्लोन पर फ़िल्टरिंग करना बेहतर होगा), लेकिन git-filter-branch पर प्राथमिकता में आपको BFG Repo-Cleaner, एक तेज़, सरल विकल्प का उपयोग करना चाहिए git-filter-branch विशेष रूप से को बड़ी फ़ाइलों को गीट रेपो से हटाने के लिए डिज़ाइन किया गया है।

डाउनलोड the Java jar (ऊपर जावा 6 या आवश्यकता होती है) और इस कमांड चलाएँ:

$ java -jar bfg.jar --strip-blobs-bigger-than 1MB my-repo.git 

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

$ git gc --prune=now --aggressive 

बीएफजी आम तौर पर 10-50x git-filter-branch चलाने की तुलना में तेजी से होता है और विकल्प इन दो आम उपयोग-मामले के अनुसार बनाए जाते हैं: निकाला जा रहा है

• पागल बिग फ़ाइलें
• निकाला जा रहा है पासवर्ड, साख & अन्य निजी डेटा

Answer 4

आपका समाधान पूरा नहीं हुआ है। आपको फ़िल्टर को फ़िल्टर करने के लिए --tag-name-filter cat को तर्क के रूप में शामिल करना चाहिए ताकि टैग में बड़ी फ़ाइलों को भी बदला जा सके। कई शाखाओं में प्रतिबद्धता हो सकती है क्योंकि आपको केवल HEAD की बजाय सभी रेफरी को संशोधित करना चाहिए। https://help.github.com/articles/remove-sensitive-data