Git के साथ बड़ी बाइनरी फ़ाइलों का प्रबंधन

Question

मैं बड़ी बाइनरी फ़ाइलों को संभालने के तरीके की राय देख रहा हूं, जिस पर मेरा स्रोत कोड (वेब ​​एप्लिकेशन) निर्भर है। वर्तमान में हम कई विकल्पों पर चर्चा कर रहे हैं:

1. बाइनरी फ़ाइलों को हाथ से कॉपी करें।
   • प्रो: निश्चित नहीं।
   • कॉन्ट्रा: मैं इसके सख्त खिलाफ हूं, क्योंकि यह एक नई साइट स्थापित करने या पुराने को माइग्रेट करने पर त्रुटियों की संभावना को बढ़ाता है। एक और बाधा उठाने के लिए बनाता है।
2. उन सभी को गिट के साथ प्रबंधित करें ।
   • प्रो: एक महत्वपूर्ण फ़ाइल को कॉपी करने के लिए 'भूल' की संभावना को हटाता है
   • कॉन्ट्रा: रिपॉजिटरी को ब्लॉट करता है और कोड-बेस को प्रबंधित करने के लिए लचीलापन कम हो जाता है और चेकआउट, क्लोन इत्यादि में काफी समय लगेगा।
3. अलग-अलग रिपोजिटरी।
   • प्रो: स्रोत कोड की जाँच / क्लोनिंग पहले की तरह तेज़ है, और छवियां अपने स्वयं के भंडार में ठीक से संग्रहीत हैं।
   • कॉन्ट्रा: परियोजना पर एक और केवल गिट रिपॉजिटरी होने की सरलता को हटाता है । यह निश्चित रूप से कुछ अन्य चीजों का परिचय देता है जिनके बारे में मैंने नहीं सोचा है।

इस बारे में आपके अनुभव / विचार क्या हैं?

भी: क्या किसी के पास कई Git रिपॉजिटरी के साथ अनुभव है और उन्हें एक परियोजना में प्रबंधित करना है?

फाइलें एक प्रोग्राम के लिए छवियां हैं जो इसमें उन फाइलों के साथ पीडीएफ उत्पन्न करती हैं। फाइलें बहुत बार नहीं बदलेंगी (जैसा कि वर्षों में), लेकिन वे एक कार्यक्रम के लिए बहुत प्रासंगिक हैं। प्रोग्राम फ़ाइलों के बिना काम नहीं करेगा।

Comments

बाइनरी फ़ाइल को नियंत्रित करने वाले संस्करण के बारे में क्या आवश्यक है? मैं संपत्ति पर काम करने वाले कलाकारों की टीमों के लिए सोच रहा हूं।

— दान

यदि यह आवश्यक है तो आपको मिलने वाले लाभ के विरुद्ध अपने उपलब्ध संसाधनों (डिस्क, बैंडविड्थ, सीपीयू समय) को संतुलित करना होगा।

— पी।

ध्यान दें कि फ़ाइल-लॉकिंग के बिना, कई लोगों को एक ही बाइनरी फ़ाइल पर काम करने की आवश्यकता होने पर गिट महान नहीं होता है।

— योयो

Git-based backup file bup भी देखें ।

— वॉनक

यहाँ वे कर रहे हैं bestechvideos.com/tag/gitcasts

— doughgle

Answer 1

यदि प्रोग्राम फ़ाइलों के बिना काम नहीं करेगा तो ऐसा लगता है कि उन्हें एक अलग रेपो में विभाजित करना एक बुरा विचार है। हमारे पास बड़े परीक्षण सूट हैं जो हम एक अलग रेपो में तोड़ते हैं लेकिन वे वास्तव में "सहायक" फाइलें हैं।

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

यहाँ Git Book से सबमॉडल्स का अच्छा परिचय है ।

Comments

"जैसा कि मैं इसे समझता हूं, आपके पास केवल आपकी छवियों का एक प्रासंगिक संशोधन होगा।" मुझे नहीं लगता कि यह सही है।

— रॉबिन ग्रीन

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

— कैस्केबेल

यह एक बहुत खराब समाधान है यदि आपके पास बड़ी बाइनरी फाइलें हैं जो कुछ नियमित अंतराल पर बदल रही हैं। हमारे पास एक रिपॉजिटरी है जो बुरी तरह से फूला हुआ है क्योंकि हर बिल्ड के साथ एक नई बाइनरी फाइल इसमें जमा हो जाती है। यदि आप विंडोज पर नहीं हैं, तो नीचे वर्णित है, अनुलग्नक एक अच्छा समाधान है। यदि आप विंडोज पर हैं ... तो आपको बस देखते रहना होगा।

— एए ग्रेप्सस

रेपो में बड़ी बाइनरी फाइल होने में एक और समस्या प्रदर्शन की है। Git को बड़ी बाइनरी फ़ाइलों के साथ सामना करने के लिए डिज़ाइन नहीं किया गया था और एक बार जब रेपो आकार 3 जी + पर चढ़ जाता है, तो प्रदर्शन जल्दी से गिर जाता है। इसका मतलब यह है कि रेपो में बड़ी बायनेरिज़ आपके होस्टिंग विकल्पों को सीमित करती हैं।

— जूल

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

— मिक्को रेंटालीनें

Answer 2

मैंने हाल ही में git-annex की खोज की जो मुझे बहुत बढ़िया लगी। इसे बड़ी फ़ाइलों को कुशलतापूर्वक प्रबंधित करने के लिए डिज़ाइन किया गया था। मैं इसे अपने फोटो / संगीत (आदि) संग्रह के लिए उपयोग करता हूं। गिट-एनेक्स का विकास बहुत सक्रिय है। फ़ाइलों की सामग्री को गिट रिपॉजिटरी से हटाया जा सकता है, केवल पेड़ की पदानुक्रम को गिट (सीमलिंक के माध्यम से) द्वारा ट्रैक किया जाता है। हालाँकि, फ़ाइल की सामग्री प्राप्त करने के लिए, पुलिंग / पुश करने के बाद एक दूसरा चरण आवश्यक है, जैसे:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

कई कमांड उपलब्ध हैं, और वेबसाइट पर एक महान दस्तावेज है। डेबियन पर एक पैकेज उपलब्ध है ।

Comments

वाह! अपवित्रता के लिए अपवित्र! यह एक विचार को लागू करता है जो मेरे पास हाल ही में था, और बहुत कुछ। यह हास्केल में कम नहीं लिखा है। गिट-मीडिया एक अच्छा विकल्प है, वैसे।

— cdunn2001

लेकिन, अनुलग्नक विंडोज का समर्थन नहीं करता है। जो गेम डेवलपर्स के लिए समस्याग्रस्त है।

— एए ग्रेपस

मैंने सुना है कि स्टीम खिड़कियों के लिए समर्थन छोड़ रहा है, और लिनक्स के लिए समर्थन जोड़ रहा है ...;) गंभीरता से हालांकि, इसे पोर्ट करना कितना मुश्किल हो सकता है? मुझे लगता है कि आपका औसत गेम डेवलपर ऐसा कर सकता है।

— सैम वॉटकिंस

@EstebanBrenes वास्तविक डील-ब्रेकर यह है कि सामान्य कॉन्फ़िगरेशन में विंडोज सिम्बलिंक को बनाने के लिए उन्नत विशेषाधिकार की आवश्यकता होती है।

— लॉरेंस होल्स्ट

मुझे यह पृष्ठ मिला । यह पढ़ता है कि अब विंडोजgit annex पर भी उपलब्ध है । अगर किसी ने कभी विंडोज में इसका परीक्षण किया है, तो मैं उसके अनुभव के बारे में सुनना चाहूंगा!

— कोइची सी। नाकामुरा

Answer 3

एक अन्य समाधान, अप्रैल 2015 के बाद से Git लार्ज फाइल स्टोरेज (LFS) (GitHub द्वारा) है।

यह का उपयोग करता Git-LFS (देखें git-lfs.github.com ) और एक सर्वर से इसका समर्थन के साथ परीक्षण किया: LFS-परीक्षण-सर्वर :
आप मेटाडाटा केवल Git रेपो में स्टोर कर सकते हैं, और कहीं और बड़ी फाइल।

Comments

lfs-test-serverउत्पादन के उपयोग के लिए नहीं घोषित किया गया है। दरअसल, मैं उत्पादन LFS सर्वर ( github.com/artemkin/git-lfs-server ) पर काम कर रहा हूं । यह प्रगति पर है, लेकिन पहले से ही सेवा करने योग्य है, और हम इसका इन-हाउस परीक्षण कर रहे हैं।

— Stas

क्या आप git lfs का उपयोग करके ऐसी बाइनरी फ़ाइल के पिछले संस्करणों की जांच कर सकते हैं?

— मुचाहो

@ मुकुहो आपको चाहिए: git checkout का सिंटैक्स अपरिवर्तित है और lfs smudge script को अभी भी कहा जाना चाहिए।

— VonC

Answer 4

Git bup पर एक नजर डालें जो Git रिपॉजिटरी में बड़े बायनेरिज़ को स्मार्टली स्टोर करने के लिए Git एक्सटेंशन है।

आप इसे एक सबमॉड्यूल के रूप में रखना चाहते हैं, लेकिन आपको रिपॉजिटरी को संभालने में मुश्किल होने की चिंता नहीं करनी होगी। उनके नमूना उपयोग के मामलों में से एक Git में VM छवियों को संग्रहीत कर रहा है।

मैंने वास्तव में बेहतर संपीड़न दर नहीं देखी है, लेकिन मेरी रिपॉजिटरी में वास्तव में बड़ी बायनेरी नहीं हैं।

आपकी माइलेज भिन्न हो सकती है।

Comments

bup भंडारण प्रदान करता है (आंतरिक रूप से अतिरेक के लिए समानता का उपयोग करके और संपीड़न, डडप और हिस्ट्री के लिए git), लेकिन यह git का विस्तार नहीं करता है। git-annex एक git एक्सटेंशन है जो बूप स्टोरेज बैकएंड प्रदान करता है ।

— तोबू

@ टोबू जब मैंने इसे पोस्ट किया, git annex अभी तक मौजूद नहीं था (मुख्यधारा की रिलीज़ में)

— sehe

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

— तोबू

Answer 5

आप git-fat का भी उपयोग कर सकते हैं । मुझे यह पसंद है कि यह केवल स्टॉक पायथन और पर निर्भर करता है rsync। यह निम्नलिखित आत्म व्याख्यात्मक आदेशों के साथ सामान्य Git वर्कफ़्लो का भी समर्थन करता है:

git fat init
git fat push
git fat pull

इसके अलावा, आपको अपने .osfat फ़ाइल को अपनी रिपॉजिटरी में जांचना होगा और अपने .gitattributes को संशोधित करके उन फ़ाइल एक्सटेंशनों को निर्दिष्ट करना होगा जिन्हें आप git fatप्रबंधित करना चाहते हैं ।

आप सामान्य का उपयोग करके एक द्विआधारी जोड़ते हैं git add, जो बदले में git fatआपके गिटटैब्यू नियम के आधार पर आह्वान करता है।

अंत में, इसका यह लाभ है कि आपके बायनेरिज़ को जिस स्थान पर संग्रहीत किया जाता है उसे रिपॉजिटरी और उपयोगकर्ताओं के बीच साझा किया जा सकता है और कुछ भी rsyncकरता है।

अद्यतन करें: यदि आप गिट-एसवीएन पुल का उपयोग कर रहे हैं तो गिट-वसा का उपयोग न करें। यह आपके सबवर्सन रिपॉजिटरी से बाइनरी फ़ाइलों को हटा देगा। हालाँकि, यदि आप शुद्ध गिट रिपॉजिटरी का उपयोग कर रहे हैं, तो यह खूबसूरती से काम करता है।

Answer 6

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

मुझे कई महीनों पहले एक बहुत ही समस्या थी: ~ 21 जीबी की एमपी 3 फाइलें, अवर्गीकृत (खराब नाम, खराब आईडी 3 की, मुझे नहीं पता कि मुझे वह एमपी 3 फ़ाइल पसंद है या नहीं ...), और तीन कंप्यूटरों पर दोहराई गई।

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

अंत में, मेरे पास केवल ~ 6 जीबी की एमपी 3 फाइलें और ~ 83 जीबी की .IT डायरेक्टरी थी। मैंने पूर्वजों के बिना, एक नई प्रतिबद्ध बनाने git-write-treeऔर उपयोग git-commit-treeकरने के लिए, और उस प्रतिबद्धता की ओर इशारा करते हुए एक नई शाखा शुरू की। उस शाखा के लिए "गिट लॉग" ने केवल एक प्रतिबद्धता दिखाई।

फिर, मैंने पुरानी शाखा को हटा दिया, केवल नई शाखा को रखा, रेफ-लॉग को हटा दिया, और "git prune" चलाया: उसके बाद, मेरे .git फ़ोल्डर्स का वजन केवल ~ 6 GB था ...

आप उसी समय-समय पर विशाल भंडार को "शुद्ध" कर सकते हैं: आपका "गिट क्लोन" तेज हो जाएगा।

Comments

मैंने एक बार कुछ ऐसा ही किया था, जहां मुझे एक रिपॉजिटरी को विभाजित करना था जिसे मैंने गलती से दो अलग-अलग लोगों में मिला दिया था। दिलचस्प उपयोग पैटर्न हालांकि। :)

— पी।

क्या यह वैसा ही होगा: rm -f .git; गिट init; जोड़ देना। ; git प्रतिबद्ध -m "इतिहास को रद्दी करें।"

— पैट नोट्ज़

हां, यह केवल मेरे एमपी केस में ही है। लेकिन कभी-कभी आप अपनी शाखाओं और टैग (सार्वजनिक रिपॉजिटरी में कोई स्थान में कमी) को छूना नहीं चाहते हैं, लेकिन आप केवल एक शाखा के "गिट क्लोन / भ्रूण / खींच" को गति देना चाहते हैं (समर्पित-से-के लिए कम जगह) शाखा भंडार)।

— डैनियल फंजुल

Answer 7

जो प्रस्ताव मैं प्रस्तावित करना चाहता हूं वह अनाथ शाखाओं और टैग तंत्र के एक छोटे से दुरुपयोग पर आधारित है, इसलिए इसे * अनाथ टैग बाइनरी स्टोरेज (OTABS) के रूप में जाना जाता है।

TL, DR 12-01-2017 यदि आप github के LFS या किसी अन्य 3rd पार्टी का उपयोग कर सकते हैं, तो हर तरह से आपको करना चाहिए। यदि आप नहीं कर सकते, तो पर पढ़ें। सावधान रहें, यह समाधान एक हैक है और इसे इस तरह से माना जाना चाहिए।

OTABS के वांछनीय गुण

• यह एक शुद्ध git और git का एकमात्र समाधान है - यह बिना किसी 3rd पार्टी सॉफ्टवेयर (जैसे git-annex) या 3rd पार्टी इंफ्रास्ट्रक्चर (जैसे github के LFS) के बिना किया जाता है।
• यह द्विआधारी फ़ाइलों को कुशलतापूर्वक संग्रहीत करता है, अर्थात यह आपके भंडार के इतिहास को प्रदर्शित नहीं करता है।
• git pullऔर git fetch, git fetch --allअभी भी बैंडविड्थ कुशल हैं , यानी सभी बड़े बायनेरिज़ डिफ़ॉल्ट रूप से रिमोट से नहीं खींचे जाते हैं।
• यह विंडोज पर काम करता है ।
• यह सब कुछ एक एकल भंडार भंडार में संग्रहीत करता है ।
• यह पुराने बायनेरिज़ (बूप के विपरीत) को हटाने की अनुमति देता है ।

OTABS के अवांछनीय गुण

• यह git cloneसंभावित रूप से अक्षम बनाता है (लेकिन जरूरी नहीं कि आपके उपयोग के आधार पर)। आप इस समाधान को तैनात यदि आप उपयोग करने के लिए अपने सहयोगियों सलाह करना पड़ सकता है git clone -b master --single-branch <url>बजाय git clone। इसका कारण यह है कि डिफ़ॉल्ट रूप से गिट क्लोन पूरे शाब्दिक रूप से क्लोन करता है, जिसमें ऐसी चीजें शामिल हैं जिन्हें आप सामान्य रूप से अपने बैंडविड्थ को बेकार नहीं करना चाहते हैं, जैसे कि अपरिचित कमिट। SO 4811434 से लिया गया ।
• यह git fetch <remote> --tagsबैंडविड्थ को अक्षम बनाता है, लेकिन जरूरी नहीं कि भंडारण अक्षम हो। आप हमेशा अपने सहयोगियों को इसका उपयोग न करने की सलाह दे सकते हैं।
• आपको समय-समय git gcपर किसी भी फाइल से अपनी रिपॉजिटरी को साफ करने के लिए एक ट्रिक का उपयोग करना होगा जिसे आप नहीं चाहते हैं।
• यह के रूप में कुशल के रूप में नहीं है BUP या Git-bigfiles । लेकिन आप जो करने की कोशिश कर रहे हैं उसके लिए यह क्रमशः अधिक उपयुक्त है और अधिक ऑफ-द-शेल्फ है। आपको सैकड़ों हजारों छोटी फाइलों के साथ या गीगाबाइट की रेंज में फाइलों के साथ चलने की संभावना है, लेकिन वर्कअराउंड के लिए पढ़ें।

बाइनरी फ़ाइलें जोड़ना

इससे पहले कि आप यह सुनिश्चित करें कि आपने अपने सभी परिवर्तन कर लिए हैं, आपका कार्य करने का पेड़ अद्यतित है और आपके सूचकांक में कोई भी परिवर्तन नहीं है। किसी भी आपदा के होने की स्थिति में अपनी सभी स्थानीय शाखाओं को अपने रिमोट (जीथूब आदि) पर धकेलना एक अच्छा विचार हो सकता है।

1. एक नई अनाथ शाखा बनाएँ। git checkout --orphan binaryStuffचाल चलेगा। यह एक ऐसी शाखा का निर्माण करता है जो किसी अन्य शाखा से पूरी तरह से डिस्कनेक्ट हो जाती है, और इस शाखा में आप जो पहली कमिटमेंट करेंगे, उसका कोई अभिभावक नहीं होगा, जो इसे रूट कमिट करेगा।
2. अपने सूचकांक का उपयोग करके साफ करें git rm --cached * .gitignore।
3. एक गहरी साँस लें और पूरे काम करने वाले पेड़ को हटा दें rm -fr * .gitignore। आंतरिक .gitनिर्देशिका अछूती रहेगी, क्योंकि *वाइल्डकार्ड इससे मेल नहीं खाता है।
4. अपने VeryBigBinary.exe, या अपने VeryHeavyDirectory / में कॉपी करें।
5. इसे जोड़ें && इसे प्रतिबद्ध करें।
6. अब यह मुश्किल हो जाता है - यदि आप इसे एक शाखा के रूप में रिमोट में धकेलते हैं तो आपके सभी डेवलपर्स इसे अगली बार डाउनलोड करेंगे जब वे git fetchअपने कनेक्शन को रोकेंगे। आप एक शाखा के बजाय एक टैग को धक्का देकर इससे बच सकते हैं। यह तब भी आपके सहकर्मी के बैंडविड्थ और फाइलसिस्टम स्टोरेज को प्रभावित कर सकता है यदि उन्हें टाइप करने की आदत है git fetch <remote> --tags, लेकिन वर्कअराउंड के लिए पढ़ें। आगे बढ़ो औरgit tag 1.0.0bin
7. अपने अनाथ टैग को पुश करें git push <remote> 1.0.0bin।
8. बस इसलिए आप कभी भी अपनी बाइनरी शाखा को दुर्घटना से नहीं धकेल सकते हैं, आप इसे हटा सकते हैं git branch -D binaryStuff। कचरा संग्रहण के लिए आपकी प्रतिबद्धता को चिह्नित नहीं किया जाएगा, क्योंकि इस पर इशारा करने वाला एक अनाथ टैग 1.0.0binइसे जीवित रखने के लिए पर्याप्त है।

बाइनरी फ़ाइल की जाँच करना

1. मैं (या मेरे सहकर्मियों) को वर्तमान कार्यशील पेड़ में VeryBigBinary.exe की जाँच कैसे करनी चाहिए? यदि आपकी वर्तमान कार्य शाखा उदाहरण के लिए है, तो आप बस कर सकते हैं git checkout 1.0.0bin -- VeryBigBinary.exe।
2. यदि आप अनाथ टैग 1.0.0binडाउनलोड नहीं करते हैं, तो यह विफल हो जाएगा , इस स्थिति में आपको git fetch <remote> 1.0.0binपहले से क्या करना होगा ।
3. आप VeryBigBinary.exeअपने मास्टर में जोड़ सकते हैं .gitignore, ताकि आपकी टीम में कोई भी दुर्घटना से बाइनरी के साथ परियोजना के मुख्य इतिहास को प्रदूषित न करे।

पूरी तरह से बाइनरी फ़ाइल को हटाना

यदि आप अपने स्थानीय रिपॉजिटरी, अपने दूरस्थ रिपॉजिटरी और अपने सहकर्मी के रिपॉजिटरी से VeryBigBinary.exe को पूरी तरह से शुद्ध करने का निर्णय लेते हैं:

1. रिमोट पर अनाथ टैग हटाएं git push <remote> :refs/tags/1.0.0bin
2. स्थानीय रूप से अनाथ टैग हटाएं (अन्य सभी अप्रकाशित टैग हटाता है) git tag -l | xargs git tag -d && git fetch --tags। मामूली संशोधन के साथ SO 1841341 से लिया गया ।
3. स्थानीय रूप से अपनी अब तक की अपरिष्कृत कमिट को हटाने के लिए git gc ट्रिक का उपयोग करें। git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"। यह अन्य सभी अपरिचित कमिटों को भी हटा देगा। SO 1904860 से लिया गया
4. यदि संभव हो, तो रिमोट पर git gc ट्रिक दोहराएं। यह संभव है यदि आप अपनी रिपॉजिटरी की स्वयं-मेजबानी कर रहे हैं और कुछ git प्रदाताओं के साथ संभव नहीं हो सकता है, जैसे github या कुछ कॉर्पोरेट वातावरण में। यदि आप एक ऐसे प्रदाता के साथ होस्ट कर रहे हैं जो आपको रिमोट तक एसएचएस एक्सेस नहीं देता है तो बस रहने दें। यह संभव है कि आपके प्रदाता का बुनियादी ढांचा आपके स्वयं के मधुर समय में आपकी अप्रतिबंधित प्रतिबद्धता को साफ कर दे। यदि आप एक कॉर्पोरेट वातावरण में हैं, तो आप अपने आईटी को सलाह दे सकते हैं कि वह एक क्रोन जॉब कचरा चलाने के लिए प्रति सप्ताह या एक बार अपना रिमोट इकट्ठा करें। चाहे वे बैंडविड्थ और भंडारण के मामले में आपकी टीम पर कोई प्रभाव नहीं डालेंगे या नहीं, जब तक आप अपने सहयोगियों को हमेशा git clone -b master --single-branch <url>इसके बजाय सलाह देते हैं git clone।
5. आपके सभी सहयोगी जो पुराने अनाथ टैग से छुटकारा चाहते हैं, उन्हें केवल चरण 2-3 लागू करने की आवश्यकता है।
6. फिर आप एक नया अनाथ टैग बनाने के लिए बाइनरी फ़ाइलों को जोड़ने के चरण 1-8 को दोहरा सकते हैं 2.0.0bin। यदि आप अपने सहकर्मियों के बारे में चिंतित हैं, तो आप git fetch <remote> --tagsवास्तव में इसे फिर से नाम दे सकते हैं 1.0.0bin। यह सुनिश्चित करेगा कि अगली बार जब वे सभी टैग 1.0.0binलाएंगे तो पुराने को अप्रकाशित किया जाएगा और बाद के कचरा संग्रह के लिए चिह्नित किया जाएगा (चरण 3 का उपयोग करके)। जब आप रिमोट पर एक टैग को अधिलेखित करने की कोशिश करते हैं तो आपको -fइस तरह का उपयोग करना होगा:git push -f <remote> <tagname>

अंतभाषण

• OTABS आपके स्वामी या किसी अन्य स्रोत कोड / विकास शाखाओं को नहीं छूता है। प्रतिबद्ध हैश, इतिहास का, और इन शाखाओं का छोटा आकार अप्रभावित है। यदि आपने पहले से ही अपने स्रोत कोड इतिहास को बाइनरी फ़ाइलों के साथ फूला हुआ है, तो आपको इसे एक अलग काम के रूप में साफ करना होगा। यह स्क्रिप्ट उपयोगी हो सकती है।

• जीआईटी-बैश के साथ विंडोज पर काम करने की पुष्टि की।

• बाइनरी फ़ाइलों के भंडारण को अधिक कुशल बनाने के लिए मानक ट्रिक्स का एक सेट लागू करना एक अच्छा विचार है । बार-बार git gc(बिना किसी अतिरिक्त तर्क के) चलने से बाइनरी डेल्टास का उपयोग करके आपकी फ़ाइलों के अंतर्निहित भंडारण का अनुकूलन होता है। हालाँकि, यदि आपकी फ़ाइलों को कमिटेड से समान रहने की संभावना नहीं है, तो आप बाइनरी डेल्टास को पूरी तरह से बंद कर सकते हैं। इसके अतिरिक्त, क्योंकि इसका कोई मतलब नहीं है कि पहले से ही संपीड़ित या एन्क्रिप्ट की गई फ़ाइलें, जैसे .zip, .jpg या .crypt को संकुचित करने के लिए, git आपको अंतर्निहित भंडारण के संपीड़न को बंद करने की अनुमति देता है। दुर्भाग्य से यह एक ऑल-एंड-नथिंग सेटिंग है जो आपके सोर्स कोड को भी प्रभावित करता है।

• आप तेज़ उपयोग की अनुमति देने के लिए OTABS के कुछ हिस्सों को स्क्रिप्ट करना चाह सकते हैं। विशेष रूप से, पूरी तरह से बाइनरी फ़ाइलों को updateगिट हुक में हटाने से 2-3 कदम स्क्रिप्टिंग एक सम्मोहक लेकिन शायद खतरनाक अर्थ विज्ञान को लाने के लिए ले सकते हैं ("भ्रूण और जो कुछ भी तारीख से बाहर है उसे हटा दें")।

• आप केंद्रीय रिपॉजिटरी ब्लोट की कीमत पर रिमोट पर सभी बाइनरी परिवर्तनों का पूरा इतिहास रखने के लिए पूरी तरह से हटाने वाली बाइनरी फ़ाइलों के चरण 4 को छोड़ना चाह सकते हैं । स्थानीय रिपोजिटरी समय के साथ दुबली रहेंगी।

• जावा की दुनिया में इस समाधान को maven --offlineअपने संस्करण नियंत्रण में पूरी तरह से संग्रहीत एक प्रतिलिपि प्रस्तुत करने योग्य ऑफ़लाइन निर्माण बनाने के लिए संभव है (यह ग्रेडल की तुलना में मावेन के साथ आसान है)। गोलंग दुनिया में इसके बजाय अपने GOPATH का प्रबंधन करने के लिए इस समाधान का निर्माण संभव है go get। अजगर की दुनिया में, स्क्रेप से हर बिल्ड के लिए PyPi सर्वर पर भरोसा किए बिना एक स्व-निहित विकास वातावरण का उत्पादन करने के लिए virtualenv के साथ इसे जोड़ना संभव है।

• अपने बाइनरी फ़ाइलें बहुत बार बदलते हैं तो निर्माण कलाकृतियों की तरह, यह स्क्रिप्ट एक समाधान है जो भंडार कलाकृतियों के 5 सबसे हाल के संस्करण अनाथ टैग में करने के लिए एक अच्छा विचार हो सकता monday_bin, tuesday_bin, ..., friday_binप्रत्येक रिलीज के लिए, और यह भी एक अनाथ टैग 1.7.8bin 2.0.0bin, आदि आप weekday_binदैनिक बायनेरिज़ को घुमा सकते हैं और हटा सकते हैं । इस तरह से आपको दो दुनियाएँ मिलती हैं: आप अपने स्रोत कोड का पूरा इतिहास रखते हैं, लेकिन केवल आपके द्विआधारी निर्भरताओं का प्रासंगिक इतिहास। किसी भी टैग के लिए द्विआधारी फ़ाइलों को प्राप्त करना बहुत आसान है, इसके पूरे इतिहास के साथ पूरे स्रोत कोड प्राप्त किए बिना : git init && git remote add <name> <url> && git fetch <name> <tag>यह आपके लिए करना चाहिए।

Comments

"आपको समय-समय पर उपयोग करना है git gc" - वहीं पढ़ना बंद कर दिया। कोई किसी हैक के पक्ष में अपना आखिरी सुरक्षा बेल्ट क्यों देगा?

— user1643723

@ user1643723 git gcचलाने के लिए असुरक्षित नहीं है। आपके सभी झूलने वाले हिट

— Adam Kurkiewicz

विस्तृत राइटअप के लिए धन्यवाद। मैं इसे अपने GitHub रेपो में कुछ बाइनरी निर्भरताओं को संग्रहीत करने के तरीके के रूप में इस तरह से कोशिश करना चाहता था कि वे डिफ़ॉल्ट रूप से डाउनलोड नहीं होते हैं जब कोई रेपो क्लोन करता है, लेकिन मैन्युअल रूप से डाउनलोड किया जा सकता है और स्थानीय रेपो को अपडेट कर सकता है। हालाँकि, मुझे इस कदम पर एक त्रुटि मिली: git push <remote> 1.0.0bin- remote: error: GH001: Large files detected. You may want to try Git Large File Storage। ऐसा लग रहा है कि शायद गिटहब अब इसका समर्थन नहीं कर रहा है? प्रश्न में बाइनरी 100 एमबी आकार में थी।

— user5359531

पूरी तरह से ईमानदार होने के लिए, यदि आपको अपने काम के लिए जीथब का उपयोग करने की अनुमति है, तो आपको एलएफएस का उपयोग करने से क्या रोकता है? इस उत्पाद को बनाने के लिए गिटबब के लोगों ने कड़ी मेहनत की है, और वे इसे आपके लिए होस्ट भी कर रहे हैं और इसका उपयोग करने के लिए उनके बुनियादी ढांचे को अनुकूलित किया गया है। यह हैक उन स्थितियों के लिए है जब आप वास्तव में LFS या अन्य तृतीय-पक्ष का उपयोग नहीं कर सकते हैं और आप शुद्ध-गिट समाधान के बाद हैं।

— एडम कुर्कविक्ज़

मैंने इस जवाब को और अधिक स्पष्ट किया है कि यह समाधान वास्तव में कितना खतरनाक है।

— एडम कुर्कविज़

Answer 8

मेरी राय में, आप अक्सर उन बड़ी फ़ाइलों को संशोधित करने के लिए की संभावना हो, या यदि आप का एक बहुत कुछ करने का इरादा है, तो git cloneया git checkout, तो आप को गंभीरता से (उन फ़ाइलों का उपयोग करने के लिए या शायद एक और तरीका है) एक और Git भंडार के उपयोग पर विचार करना चाहिए।

लेकिन अगर आप काम करते हैं जैसे हम करते हैं, और यदि आपकी बाइनरी फाइलें अक्सर संशोधित नहीं होती हैं, तो पहला क्लोन / चेकआउट लंबा होगा, लेकिन उसके बाद यह उतना ही तेज होना चाहिए जितना आप चाहते हैं (अपने उपयोगकर्ताओं को पहले क्लोन रिपोजिटरी का उपयोग करते हुए रखना चाहिए) था)।

Comments

और, अलग-अलग रेपो चेकआउट के समय को कम नहीं करेंगे, क्योंकि आपको अभी भी दोनों रेपो की जांच करनी है!

— एमिल

यदि आप "बाइनरी रेपो" के इतिहास को लगातार साफ़ करते हैं तो @ ईमलीसिट अलग रेपो चेकआउट को बहुत छोटा बना सकता है। इसके अलावा देवों को हर बार दोनों रेपो की जांच करने के लिए मजबूर नहीं किया जाएगा ।

— FabienAndre

क्यों न केवल मुख्य मॉड्यूल का निर्माण स्क्रिप्ट दूसरी रेपो से बाइनरी फ़ाइलों को लाने के लिए है, उन्हें एक-एक करके (जैसे: stackoverflow.com/questions/1125476/… ) निकालने ।

— एकुप्पी

यहां तक ​​कि अगर आपकी बाइनरी फाइलें बार-बार नहीं बदली जाती हैं, तो बड़ी फाइलें अभी भी आपके वर्कफ़्लो को मार सकती हैं, यदि आप शाखाओं को अक्सर सहयोग के उद्देश्य से रिपॉजिटरी में डालते हैं।

— टिमो रीमैन

Answer 9

एसवीएन बाइनरी डेल्टास को गिट की तुलना में अधिक कुशलता से संभालने के लिए लगता है।

मुझे प्रलेखन के लिए एक संस्करण प्रणाली पर निर्णय लेना था (जेपीईजी फाइलें, पीडीएफ फाइलें, और .odt फाइलें)। मैंने अभी एक जेपीईजी फ़ाइल को जोड़ने और 90 डिग्री को चार बार (बाइनरी डेल्टास की प्रभावशीलता की जांच करने के लिए) घुमाया। Git का भंडार 400% बढ़ गया। एसवीएन का भंडार केवल 11% बढ़ा।

तो ऐसा लगता है कि एसवीएन बाइनरी फ़ाइलों के साथ बहुत अधिक कुशल है।

इसलिए मेरी पसंद जीआईटी फाइल के लिए सोर्स कोड और एसवीएन जैसे डॉक्यूमेंटेशन के लिए है।

Comments

आपको बस उन 4 फाइलों को जोड़ने के बाद "git gc" (रिपैकिंग और कचरा एकत्रित करना) चलाने की आवश्यकता थी। Git सभी जोड़े गए कंटेंट को तुरंत संपीड़ित नहीं करता है, जिससे आपके पास एक ग्रुप-ऑफ-फाइल्स कम्प्रेशन होगा (जो आकार के मामले में अधिक कुशल है) और अलग-अलग हर एक जोड़े हुए ऑब्जेक्ट को वहाँ से अलग करने की मंदी नहीं होगी। लेकिन यहां तक ​​कि "गिट जीसी" के बिना, गिट ने आपके लिए अंततः संपीड़न किया होगा, वैसे भी (इसके बाद देखा, कि पर्याप्त अनपैक किए गए ऑब्जेक्ट जमा हो गए हैं)।

— नाइटिंगेल 8

@ जिपरसन मैंने एक खाली गिट रिपॉजिटरी बनाई और (और प्रतिबद्ध) 41MB के आकार के साथ एक पूरी तरह से सफेद बीएमपी छवि को जोड़ा, इससे कुल गिट रिपॉजिटरी 328KB के आकार के साथ हुई। एक के बाद git gcकुल Git भंडार आकार 184kb करने के लिए कम हो गया था। फिर मैंने एक पिक्सेल को सफेद से काले रंग में बदल दिया और इस बदलाव को किया, कुल गिट रिपॉजिटरी का आकार बढ़कर 388KB हो गया और git gcकुल गिट रिपॉजिटरी का आकार घटकर 184KB हो गया। इससे पता चलता है कि द्विआधारी फ़ाइलों के डेल्टा को संकुचित करने और खोजने में गिट बहुत अच्छा है।

— तदवीर

@ जिपरसन ए सिडेनोट: मैंने अभी बाइनरी डेल्टास पर टिप्पणी की है। अगर यह बड़ी (GB आकार) फ़ाइलों के साथ रिपॉजिटरी का प्रबंधन कर रहा है, तो Git आपकी सभी मेमोरी खाएगा और स्वैप करेगा। इसके लिए, git-annex (पहले से ही एक अन्य उत्तर में उल्लिखित) का उपयोग करें ...

— Tader

@JDDvorak - किसी ने भी इसका उल्लेख नहीं किया है, क्योंकि यह पूरी तरह से असत्य है। पृष्ठ के मध्य के बारे में सबवर्सन कॉपियाँ सस्ती हैं - svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html -।

— जॉरिस टिम्मरमैन

@ टैडर: आपका टेस्ट खराब है। जिसे आप बाइनरी फाइल कहते हैं, वह वास्तव में (git के नजरिए से) एक टेक्स्ट फाइल की तरह है - बिटस्ट्रीम बाइट-अलाइन है, और इसमें अर्थपूर्ण, स्थानीयकृत रूपांतर किए जाते हैं; आखिरकार, एक पिक्सेल बदलना मूल रूप से एक टेक्स्ट फ़ाइल में एक चरित्र को बदलने के बराबर है (और जो आजकल असम्पीडित बिटमैप का उपयोग करता है;) एक छोटे वीडियो, संपीड़ित छवि, वर्चुअल मशीन, जिपफाइल या जो भी हो - के साथ एक ही प्रयोग की कोशिश करें और आप पाएंगे यह डेल्टा कुशलता से व्यवहार नहीं करता है; वास्तव में यह अतुल्य डेटा के साथ मौलिक रूप से असंभव है।

— Eamon Nerbonne

Answer 10

git clone --filter गेट 2.19 + उथले क्लोन से

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

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

इसके साथ, हम पहले एक उथले क्लोन कर सकते थे, और फिर प्रत्येक प्रकार के निर्माण के लिए बिल्ड सिस्टम के साथ लाने के लिए जो स्वचालित रूप से खिलता है।

यहां तक ​​कि पहले से ही एक है --filter=blob:limit<size>जो अधिकतम बूँद आकार को सीमित करने की अनुमति देता है।

मैंने इस बात का एक न्यूनतम विस्तृत उदाहरण प्रदान किया है कि यह फीचर कैसा दिखता है: मैं केवल Git रिपॉजिटरी के एक उपनिर्देशिका को कैसे क्लोन करूं?

Answer 11

मैं बड़ी बाइनरी फ़ाइलों को संभालने के तरीके की राय देख रहा हूं, जिस पर मेरा स्रोत कोड (वेब ​​एप्लिकेशन) निर्भर है। इस बारे में आपके अनुभव / विचार क्या हैं?

मेरे व्यक्तिगत रूप से 3 जीबी मार्क के ऊपर बाइनरी डेटा नोट किए जाने के बाद, मैंने अपने कुछ क्लाउड होस्ट्स के साथ Git के साथ सिंक्रोनाइज़ेशन विफलताओं में भाग लिया है । मैंने उस समय BFT रेपो क्लीनर पर विचार किया, लेकिन यह एक हैक की तरह लगा। तब से मैंने सिर्फ Git के दायरे से बाहर फाइलें रखना शुरू कर दिया है, इसके बजाय फ़ाइलों, संस्करण और बैक-अप के प्रबंधन के लिए अमेज़न S3 जैसे उद्देश्य-निर्मित उपकरण का लाभ उठा रहा हूं ।

क्या किसी के पास कई Git रिपॉजिटरी के साथ अनुभव है और उन्हें एक परियोजना में प्रबंधित करना है?

हाँ। ह्यूगो थीम मुख्य रूप से इस तरह से प्रबंधित की जाती हैं। यह थोड़ा कुडगी है, लेकिन इससे काम हो जाता है।

---

मेरा सुझाव काम के लिए सही उपकरण चुनना है । यदि यह किसी कंपनी के लिए है और आप GitHub पर अपनी कोडलाइन का प्रबंधन कर रहे हैं तो पैसे का भुगतान करें और Git-LFS का उपयोग करें। अन्यथा आप ब्लॉकचैन का उपयोग करके अधिक रचनात्मक विकल्प जैसे विकेंद्रीकृत, एन्क्रिप्टेड फ़ाइल संग्रहण का पता लगा सकते हैं ।

विचार करने के लिए अतिरिक्त विकल्पों में मिनियो और s3cmd शामिल हैं ।

Answer 12

कैमलिस्ट पर एक नजर । यह वास्तव में Git- आधारित नहीं है, लेकिन मुझे यह अधिक उपयुक्त लगता है कि आपको क्या करना है।