Git में बड़े फ़ाइलों का भविष्य खुद Git है

 (tylercipriani.com)
13 पॉइंट द्वारा GN⁺ 2025-08-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Git project ने हाल ही में आधिकारिक रूप से बड़े फ़ाइल प्रबंधन की समस्या को सीधे हल करना शुरू किया है
  • Git LFS यूज़र्स के लिए कई तरह की लागत, vendor lock-in आदि पैदा करने वाला एक अस्थायी उपाय है
  • हाल की partial clone सुविधा के साथ अब Git खुद ही LFS की ज़्यादातर भूमिका को बदल सकता है
  • आगे large object promisor नाम का एक नया समाधान भी आधिकारिक Git में इंटीग्रेट होने की तैयारी में है
  • इन बदलावों के साथ बड़े फ़ाइल प्रबंधन का अंतिम समाधान किसी बाहरी extension की बजाय खुद Git पर आकर टिकने की संभावना है

Git में बड़े फ़ाइलों की समस्या और बदलाव

  • अगर Git का सबसे बड़ा nemesis कोई है, तो वह है बड़ी फ़ाइलें
  • बड़ी फ़ाइलें Git repository को फुला देती हैं, git clone की गति कम करती हैं, और ज़्यादातर hosting environments पर भी बुरा असर डालती हैं

Git LFS का आगमन और सीमाएँ

  • 2015 में GitHub ने बड़े फ़ाइलों की समस्या को बायपास करने के लिए Git LFS जारी किया
  • लेकिन Git LFS खुद नई complexity और storage cost जोड़ देता है
  • Git community चुपचाप बड़े फ़ाइलों की मूल समस्या पर विचार करती रही है, और हाल की Git की आधिकारिक रिलीज़ में LFS के बिना बड़े फ़ाइलों को मैनेज करने की नई दिशा सामने आई है

आज ही अपनाया जा सकने वाला तरीका: Git LFS को partial clone से बदलना

  • partial clone कैसे काम करता है

    • Git LFS: बड़ी फ़ाइलों को repository के बाहर रखा जाता है, और काम करते समय केवल ज़रूरी फ़ाइलें डाउनलोड की जाती हैं
    • Git partial clone (2017 में पेश किया गया):
      • --filter option से तय आकार से बड़े blobs को छोड़कर clone करना
      • ज़रूरत पड़ने पर केवल वही बड़ी फ़ाइलें सर्वर से डाउनलोड करना

      Partial clone का उपयोग करने पर Clone और Fetch के दौरान [बड़ी binary assets] को पहले से डाउनलोड करने की ज़रूरत नहीं पड़ती, जिससे download time और disk usage कम होता है

  • partial clone और LFS में समानताएँ

    • 1. checkout size को न्यूनतम रखना: सिर्फ़ latest version लिया जाता है और पूरी file history छोड़ी जाती है
    • 2. तेज़ clone: बड़ी फ़ाइलों का transfer नहीं होने से clone तेज़ होता है
    • 3. तेज़ setup: shallow clone के विपरीत, पूरे project history तक पहुँचना संभव रहता है

  • partial clone के उपयोग का उदाहरण

    • बहुत अधिक large PNG file history वाले repo की clone speed और disk usage का उदाहरण:
      • सामान्य clone में लगभग 4 मिनट और 1.3GB space लगता है
      • partial clone और 100KB blob limit लगाने पर 6 सेकंड में clone, 49MB उपयोग
      • मूल की तुलना में clone speed 97% बेहतर, checkout size 96% कम

  • partial clone की सीमाएँ

    • जब filtered data की ज़रूरत होती है (जैसे git diff, git blame, git checkout), Git सर्वर से फ़ाइल माँगता है
    • यह Git LFS जैसी ही विशेषता है
    • व्यवहार में binary files पर blame करना बहुत कम होता है

Git LFS की समस्याएँ

  • उच्च vendor lock-in: GitHub implementation केवल अपने server को support करती है, जिससे शुल्क और निर्भरता पैदा होती है
  • लागत की समस्या: 50GB storage पर GitHub LFS की सालाना लागत $40, जबकि Amazon S3 पर $13
  • वापस लौटना मुश्किल: एक बार LFS में बदलने के बाद history rewrite किए बिना पुराने रूप में लौटना संभव नहीं
  • लगातार setup cost: हर collaborator के लिए LFS install करना ज़रूरी, वरना फ़ाइलों की जगह metadata files दिखती हैं, जिससे भ्रम होता है

आगे की दिशा: Large Object Promisor

  • बड़ी फ़ाइलें hosting platforms (GitHub, GitLab) के लिए भी लागत की समस्या पैदा करती हैं
  • Git LFS बड़ी फ़ाइलों को CDN पर offload करके server cost कम करता है

  • Large Object Promisor क्या है?

    • इस साल की शुरुआत में Git ने large object promisor नाम की सुविधा को आधिकारिक रूप से merge किया
    • यह सुविधा LFS की तरह server-side storage burden कम करती है, लेकिन user complexity को काफ़ी घटाती है

      यह प्रयास server side के काम को, खासकर उन बड़े blobs के लिए जो पहले से binary format में compressed हैं, बेहतर बनाने के लिए है
      यह Git LFS का एक विकल्प बनने वाला समाधान है
      – Large Object Promisors, git-scm.com

  • यह कैसे काम करता है

    • 1. यूज़र बड़ी फ़ाइलों को Git host पर push करता है
    • 2. host backend promisor पर बड़ी फ़ाइलों को offload कर देता है
    • 3. clone के समय Git host client को promisor की जानकारी देता है
    • 4. client ज़रूरत पड़ने पर उसी promisor से बड़ी फ़ाइलें अपने-आप प्राप्त कर लेता है

  • मौजूदा स्थिति और चुनौतियाँ

    • large object promisor अभी development में है, और मार्च 2025 में इसका कुछ code Git में merge हुआ
    • GitLab आदि में अतिरिक्त implementation और unresolved issues पर चर्चा जारी है
    • व्यापक adoption तक अभी समय लगेगा
    • फिलहाल बड़ी फ़ाइल storage के लिए Git LFS पर निर्भरता टालना मुश्किल है
    • promisor के फैलने पर GitHub में 100MB से बड़ी फ़ाइलें upload करना भी संभव हो सकता है

निष्कर्ष: Git में बड़े फ़ाइलों का भविष्य Git ही है

  • Git project आपकी तरफ़ से बड़ी फ़ाइलों की समस्या पर लगातार काम कर रहा है
  • अभी भी Git LFS का उपयोग ज़रूरी है
  • लेकिन partial clone और large object promisors के विकास के साथ Git LFS धीरे-धीरे अनावश्यक होता जाएगा, और जल्द ही ऐसा समय आ सकता है जब बड़े फ़ाइलों को सिर्फ़ Git से आसानी से मैनेज किया जा सके
  • भविष्य में Git में MP3 library डालने का विचार ही बड़े पैमाने के उपयोग का आख़िरी असली अवरोध रह जाएगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-16
Hacker News टिप्पणियाँ

  • पुराने svn के समय में भी 150GB की working directory, जिसमें बहुत सारी बड़ी binary files हों, बिना किसी खास समस्या के ठीक चलती थी, जबकि git ऐसा नहीं कर पाता। यह जानने की जिज्ञासा है कि svn बड़ी binary files के लिए git से अलग कौन-सा approach अपनाता है, और क्या git भी वैसा नहीं कर सकता। इसके अलावा, binary data के साथ काम करते समय file locking एक ज़रूरी feature है; ताकि किसी खास file पर एक समय में सिर्फ एक व्यक्ति काम करे और बाकी लोग उसे read-only रखें, जिससे उलझाऊ merge समस्याओं से बचा जा सके। बड़ी files को बाहर offload करने से वास्तव में performance या reliability की समस्या बेहतर होती है या नहीं, यह भी साफ़ नहीं है। आख़िर repository तो repository ही है, बस जगह अलग है। offload करना असल में public git forge द्वारा बड़ी files के storage cost से बचने का तरीका लगता है

    • git और svn का design पूरी तरह अलग है। git पूरी तरह distributed है, इसलिए हर repository को हर file की पूरी history रखनी पड़ती है, और locking की धारणा वहाँ मायने नहीं रखती। project के हिसाब से version control system चुनना चाहिए; यह ज़रूरी नहीं कि git हर काम के लिए universal हो

  • Large object promisors का concept पसंद आया। अगर S3 जैसी जगह को आसानी से जोड़कर इस्तेमाल किया जा सके, तो शायद मौजूदा LFS से तुरंत migrate करूँ। बड़ी binary files का version control करते समय S3 के साथ अच्छा synergy बनता है। intelligent tiering की वजह से data पुराना होने पर अपने-आप सस्ती storage tier में चला जाता है, यह भी फ़ायदा है। 10 साल पुराने data को restore करने में आधा दिन लग जाए तो भी कोई दिक्कत नहीं

    • मैं भी यही सोचता हूँ। समझ नहीं आता कि शुरू से यह default तरीका क्यों नहीं था। मैं एक छोटा git LFS server खुद चला रहा हूँ, और अगर git सिर्फ S3 को native support दे दे, तो मैं तुरंत switch करने को तैयार हूँ

    • अपनी मौजूदा नौकरी में हम cost बचाने के लिए LFS objects को bucket में cache कर रहे हैं। हर PR run पर git lfs ls-files से file list लेते हैं, gcp से fetch करते हैं, git lfs checkout से objects को local में store करते हैं, फिर pull से सिर्फ जो छूट गए हों वही और लेते हैं। जो files cached नहीं होतीं, उन्हें gcloud storage rsync से वापस bucket में upload कर देते हैं। developer के नज़रिए से कोई अतिरिक्त setup नहीं चाहिए; बस नए objects pull हो जाते हैं, और GitHub UI में भी repository state को लेकर कोई confusion नहीं होता। पहले सोचा था कि अपना LFS backend खड़ा करें, लेकिन इस तरीके ने अभी की सबसे बड़ी समस्या हल कर दी। GitHub पर LFS files को CI में हर बार लेने पर traffic charge बहुत ज़्यादा पड़ता था, और cache की 10GB limit तथा branches के बीच sharing न होने की वजह से हर बार फिर से डाउनलोड करना पड़ता था। cache capacity को पैसे देकर भी बढ़ाना चाहता था, लेकिन वह विकल्प भी नहीं था। इसे developers पर लागू करना भी आसान है; बस एक git hook जोड़ना होता है

    • क्या S3 Amazon से जुड़ी service है?

  • Git LFS की कई कमियाँ गिनाने पर सहमत हूँ, लेकिन यह कहना कि इसमें vendor lock-in है, उससे सहमत नहीं हूँ। GitHub open client और server देता है, इसलिए यह दावा उचित नहीं लगता। हाँ, LFS offline या sneaker-net workflows में काम नहीं करता; यह आम मामला नहीं है, लेकिन इसका ज़िक्र होना चाहिए। large object promisor ऐसा लगता है जैसे LFS की client-side complexity को server पर शिफ्ट कर देता है, यानी जटिलता बस जगह बदलती है। अगर architecture ऐसा है कि git server files को LFS server और object storage पर upload करता है, तो उसके अपने trade-off होंगे। यह भी जिज्ञासा है कि public git server पर promisor remote को छिपाकर uploads होने पर क्या होगा

    • मुझे सच में लगता है कि LFS काफ़ी खराब है। server implementation भी बिखरा हुआ है, और object content तथा उसे store करने का तरीका आपस में गड्डमड्ड हैं। opt-in तरीका भी बहुत खराब है; बिना सोचे-समझे इस्तेमाल करो तो असली file की जगह सिर्फ़ छोटी text file बनती है। नया solution बेहतर होगा या नहीं, पता नहीं, लेकिन इतना तय है कि LFS अच्छा नहीं है

    • हाल ही में Git LFS की एक और समस्या पता चली: migration ऊपर वाले commits की .gitattributes तक दूषित कर देता है। यानी अगर commits का क्रम A→B→C है और सिर्फ C में बड़ी file को LFS में जोड़ा गया, तो A और B में भी ऐसी .gitattributes आ जाती है जो मौजूद ही न होने वाली LFS files को point करती है। ऐसा इसलिए होता है क्योंकि migration प्रक्रिया .gitattributes को history में उलटी दिशा में propagate कर देती है, और यह नहीं देखती कि current commit में वह entity वास्तव में मौजूद है या नहीं

    • पहले Git LFS में SSH support नहीं था, इसलिए SSL certificate लेना अनिवार्य था। इस वजह से घर पर self-hosting करने वालों के लिए entry barrier बन जाता था। लगता है GitLab ने हाल में SSH support का patch जोड़ा है

  • software engineering की class में सलाह दी गई थी कि बड़ी files, जैसे media वगैरह, Git में न रखें बल्कि artifact repository (Artifactory आदि) में रखें। तब उन्हें snapshot dependency के रूप में deploy किया जा सकता है, और build system को इस तरह नियंत्रित किया जा सकता है कि वह सिर्फ़ latest version ही fetch करे। साथ ही, teammates की local machines पर जमा पुरानी files भी सिर्फ़ build system cache साफ़ करते ही हट जाती हैं

    • यह तरीका कुछ हद तक git submodule जैसा लगता है। अगर submodule से समस्या हल हो जाती, तो लोग अब तक इसका इस्तेमाल कर चुके होते। git submodule shallow clone भी support करता है (संबंधित लिंक: https://stackoverflow.com/questions/2144406/how-to-make-shallow-git-submodules). मैंने खुद कभी बड़ी files की समस्या नहीं झेली, इसलिए जानना चाहता हूँ कि अगर यह तरीका काम नहीं करता, तो उसकी वजह क्या है। SO पर बताए गए नुकसान इतने बड़े नहीं लगते

    • क्या class में CI/CD system architecture भी सिखाया जाता है? आजकल नए engineers पूरे integration stack, जैसे GitLab, Artifactory, CodeSonar, Anchore आदि, के साथ सहज नहीं होते

    • इस तरीके की भी कमियाँ हैं। CI/CD system या developers को अतिरिक्त credentials चाहिए होते हैं। commits की प्रक्रिया भी कई चरणों में बढ़ जाती है; पहले artifact ID पता होना चाहिए, और इसे automate करने के लिए git hook इस्तेमाल करें तो आख़िर में चीज़ें फिर git-lfs जितनी जटिल हो जाती हैं

  • यह लेख LFS का अनुचित मूल्यांकन कर रहा है। LFS, GitHub पर निर्भर नहीं है और उसका protocol भी open है। LFS की कमियाँ, git extension होने की वजह से कुछ हद तक अपरिहार्य हैं, और promisors भी मूलतः उसी तरह की अवधारणा हैं। फर्क सिर्फ़ इतना है कि इसे git के अंदर built-in कर देने से UX थोड़ा बेहतर हो गया है

    • जिस repository में एक बार भी LFS इस्तेमाल हो जाए, वह हमेशा के लिए lock-in हो जाती है। इस्तेमाल किया गया storage कम करना हो तो पूरी repository delete करनी पड़ती है, और यह बात आधिकारिक रूप से साफ़-साफ़ बताई भी नहीं जाती। हमारी company ने GitHub statistics का अध्ययन करते समय बड़ी compressed DB files को LFS में डाला था, तब यह समस्या सीधे झेली

  • यह असली solution नहीं है। git LFS भी बस एक stopgap है, और clone करते समय filter argument डालना भी बुनियादी हल नहीं है। git clone वह command है जो हर user सबसे पहले सीखता है; ऐसे में हर बार filter याद रखना पड़े, गलती हो जाए तो बहुत समय बर्बाद हो, और सही करने पर भी cloned repository शायद ठीक से काम न करे—यह सही दिशा नहीं है। असली समाधान तो rsync जैसी संरचना की ओर जाना होगा, जहाँ latest files को पहले कुशलतापूर्वक लाया जाए। git ऐसे बुनियादी बदलाव आसानी से नहीं करता

    • पूरी तरह सहमत हूँ। git अक्सर किसी समस्या को एक और flag जोड़कर "solve" करता है, लेकिन ज़्यादातर users को इन features की जानकारी ही नहीं होती। अगर defaults को ही बेहतर बनाया जाए, तो compatibility तोड़े बिना भी समस्या हल की जा सकती है

    • cloned repository शायद ठीक से काम न करे
      असल में सिर्फ़ blob history नहीं आती

    • कहा जा रहा है कि rsync ने यह समस्या हल कर दी, तो व्यावहारिक रूप में यह कैसा दिखता है? algorithm नहीं, बल्कि जब user git clone करता है, तब local filesystem पर वास्तव में क्या बनता है—यह जानना चाहता हूँ

    • अगर repository के आकार का ज़्यादातर हिस्सा पुरानी revisions में है, तो rsync की तरह पहले latest version लाने वाला तरीका अधिकांश users के लिए सबसे उपयुक्त समाधान है

  • Git core में बड़ी files के support का आना बहुत खुशी की बात है। चाहे external solution हो, opt-in संरचना अंततः मिलती-जुलती ही रहती है। मेरा लक्ष्य commands को यथासंभव कम रखना और इसे seamless बनाना था, इसलिए API को .gitattributes file के smudge/clean filters तक सीमित रखकर design किया। साथ ही, Atlassian और Microsoft के साथ सीधे काम करके vendor lock-in हटाने की कोशिश की, और file locking API में Atlassian से काफ़ी मदद मिली। LFS को तीन hosts पर compatible support के साथ open source के रूप में दिया गया है

  • हम git या git-lfs में आने वाली समस्याओं को हल करने के लिए oxen बना रहे हैं। यह git interface को ज्यों का त्यों follow करता है, लेकिन बड़ी files और लाखों files वाले monorepo environment में बहुत तेज़ चलता है। हम open source CLI और server देते हैं; दिलचस्पी हो तो feedback दें
    https://github.com/Oxen-AI/Oxen

  • git की storage पद्धति को भी restic या borg जैसे आधुनिक backup tools की तरह files और directories की content-defined chunking पर आधारित तरीके से overhaul करने की ज़रूरत है

  • GitLFS की कमियों में authentication issue छूट गया है। अगर SSH-agent इस्तेमाल न करें, तो एक push के दौरान भी कई बार authentication से गुजरना पड़ता है। मेरे अनुभव में कभी-कभी दो या तीन बार से भी ज़्यादा करना पड़ा है