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

 (tylercipriani.com)
13 पॉइंट द्वारा GN⁺ 2025-08-16 | अभी कोई टिप्पणी नहीं है. | 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 Design Notes, git-scm.com

  • 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 डालने का विचार ही बड़े पैमाने के उपयोग का आख़िरी असली अवरोध रह जाएगा

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.