Git के अगले 10 साल के लिए विकास

 (lwn.net)
21 पॉइंट द्वारा GN⁺ 2026-02-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दुनिया भर के डेवलपर्स द्वारा इस्तेमाल किया जाने वाला Git आने वाले 10 सालों की तैयारी के लिए संरचनात्मक बदलाव आगे बढ़ा रहा है, और सुरक्षा·स्केलेबिलिटी·उपयोगिता को केंद्र में रखकर बड़े सुधार किए जा रहे हैं
  • सबसे ध्यान खींचने वाला बदलाव SHA-1 से SHA-256 में संक्रमण है। 2030 तक SHA-1 के उपयोग पर रोक लगने वाली है, लेकिन ecosystem support की कमी के कारण इसका अपनाया जाना धीमा है
  • Reftable को अपनाकर लाखों references को कुशलता से प्रबंधित करने और filesystem constraints तथा concurrency समस्याओं को हल करने की कोशिश जारी है
  • बड़े आकार की फ़ाइलों को बेहतर ढंग से संभालने के लिए Large-object promisors और plugin-able object database विकसित किए जा रहे हैं, और Git 2.50 के बाद के versions में इन्हें धीरे-धीरे एकीकृत किया जा रहा है
  • Jujutsu जैसे उभरते version control systems के प्रभाव से Git UI को सरल बनाने और नए commands जोड़ने के जरिए modern workflow को support करना चाहता है

Git में बदलाव की ज़रूरत

  • 2005 में रिलीज़ होने के बाद से Git 20 सालों में लाखों repositories और अनगिनत scripts पर निर्भर एक मुख्य टूल बन चुका है
    • लेकिन SHA-1 की सुरक्षा कमजोरियाँ, बड़े repositories की बढ़ोतरी, और CI pipelines के प्रसार जैसी पर्यावरणीय बदलाओं ने इसकी संरचनात्मक सीमाएँ उजागर कर दी हैं
  • SHA-1 में 2017 में CWI और Google के SHAttered attack के जरिए collision की संभावना साबित हुई थी
    • GPU compute power में बढ़ोतरी के कारण अब बड़े संगठन hash collision की गणना कर सकने के स्तर तक पहुँच चुके हैं
  • Git को क्रांतिकारी redesign के बजाय क्रमिक विकास चुनना होगा, और वह मौजूदा ecosystem के साथ compatibility बनाए रखते हुए बदलाव आगे बढ़ा रहा है

SHA-256 संक्रमण

  • Git 2.29 (अक्टूबर 2020) में SHA-256 support जोड़ा गया था, लेकिन GitHub जैसे बड़े platforms अब भी इसे support नहीं करते
    • Git, Dulwich, Forgejo में पूर्ण support है, जबकि GitLab·go-git·libgit2 में experimental support चरण में है
  • SHA-1 का उपयोग साधारण integrity verification के लिए होता है, लेकिन signing·CI·scripts सहित पूरे ecosystem का काम collision resistance को मानकर चलता है
  • सरकारी और कॉरपोरेट नियमों के अनुसार 2030 तक SHA-1 को हटाना ज़रूरी है, और Git 3.0 में SHA-256 default बनने वाला है
  • ecosystem transition के लिए users को tools की testing और forge support request के जरिए भागीदारी करने की सलाह दी गई है

Reftable को अपनाना

  • मौजूदा Git हर reference को अलग फ़ाइल में स्टोर करने वाली loose reference structure का उपयोग करता है
    • करोड़ों references वाले repositories में यह अक्षम हो जाता है, और filesystem case-sensitivity समस्याएँ तथा concurrency inconsistency पैदा होती हैं
  • Reftable एक binary format आधारित table structure है, जिससे atomic updates और references का कुशल प्रबंधन संभव होता है
    • GitLab के 2 करोड़ references वाले repository उदाहरण में मौजूदा packed-refs फ़ाइल को 2GB फिर से लिखने की ज़रूरत पड़ती है
  • Git 3.0 में Reftable default backend बन जाएगा, और सीधे फ़ाइल access की जगह Git commands का उपयोग करने की सिफारिश की जा रही है

बड़े आकार की फ़ाइलों की प्रोसेसिंग में सुधार

  • Git text files को compress करने में कुशल है, लेकिन binary files में बदलाव होने पर पूरे object को फिर से बनाना पड़ता है, जिससे अक्षम्यता पैदा होती है
    • GitLab के विश्लेषण के अनुसार repository space का 75% हिस्सा 1MB से बड़े binary files लेते हैं
  • Large-object promisors फीचर बड़े objects को अलग remote storage में रखता है, जिससे उन्हें CDN या S3 API के जरिए ट्रांसफर किया जा सकता है
    • Git 2.50~2.52 में protocol implementation पूरा हो चुका है, और अब client-side उपयोग संभव है
  • plugin-able object database binary-विशिष्ट storage format लाएगा, जिससे incremental storage को support किया जा सकेगा
    • Git 2.53 में unified object database interface जोड़ा गया, और 2.54 में proof of concept (PoC) आने की उम्मीद है

उपयोगकर्ता इंटरफ़ेस में सुधार

  • Git commands की जटिलता और consistency की कमी को लेकर लंबे समय से आलोचना होती रही है, और Rust आधारित Jujutsu(JJ) एक विकल्प के रूप में उभरा है
    • Jujutsu history का automatic rearrangement, conflicts को data की तरह संभालना, और commits को draft की तरह treat करना जैसी सुविधाएँ देता है
  • Git मौजूदा workflow को तोड़े बिना Jujutsu के कुछ फ़ायदे अपना रहा है
    • Git 2.54 में git history split, git history reword commands जोड़े जाने की योजना है
    • आगे और भी कई history editing subcommands जोड़े जाने की योजना है
  • Steinhardt ने ज़ोर देकर कहा कि Git प्रतिस्पर्धा से सीख रहा है, और UI modernization तथा usability improvement पर काम जारी है

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

1 टिप्पणियां

 
GN⁺ 2026-02-16
Hacker News की टिप्पणियाँ

  • Git सच में बेहतरीन सॉफ़्टवेयर है, लेकिन इसमें प्रोग्रामर-केंद्रित जटिलता खुलकर दिखती है
    मैंने non-developer भूमिकाओं वाले लोगों को Git सिखाने की कोशिश की है, लेकिन वे इसकी सूक्ष्म ताकत का पूरा उपयोग नहीं कर पाए
    Learn Git Branching जैसी साइटें शानदार learning resources हैं। काश ऐसा UX Git के डिफ़ॉल्ट अनुभव में ही शामिल होता — जैसे intuitive defaults और progressive learning flow
    आजकल Claude, Codex, OpenCode जैसे agent CLI का इस्तेमाल करके ऐसा अनुभव आसानी से दिया जा सकता है। लेकिन अगर Git खुद ही ज़्यादा accessible abstraction देता, तो यह और भी आसान होता

    • समस्या यह नहीं है कि Git जटिलता दिखाता है, बल्कि यह है कि वह उस जटिलता को गलत terminology और concepts, और बेतरतीब documentation के ज़रिए व्यक्त करता है

  • Git 3.0 का सच में इंतज़ार है, लेकिन साथ ही तुरंत निराश होने के लिए भी तैयार हूँ 😅
    jj ने Git users की बहुत मदद की है। क्योंकि इसने दिखाया कि एक ज़्यादा intuitive VCS frontend संभव है

    • जितनी ज़्यादा competition होगी, ecosystem को उतना ही अच्छा प्रोत्साहन मिलेगा

  • मैंने GitLab में 2GB का packed-refs file हर कुछ सेकंड में फिर से लिखे जाते देखा है, और समझ नहीं आता कि “आख़िर ऐसा क्यों हो रहा है”

    • और सच कहूँ, मुझे यह भी नहीं पता कि ऐसी स्थिति की परवाह Git को या उस व्यक्ति को करनी भी चाहिए या नहीं

  • बड़े files को बाहर स्टोर करना centralised model की ओर एक कदम जैसा लग सकता है, लेकिन यह Git की शुरुआती design philosophy के खिलाफ़ है

    • ज़रूरी नहीं। यह सिर्फ addressing model और interface का मामला है। आप central repository इस्तेमाल कर सकते हैं, लेकिन IPFS जैसे distributed storage का भी इस्तेमाल कर सकते हैं
    • सही। Git एक DVCS है, कोई general-purpose DVFS नहीं। मुझे document storage के लिए DVFS चाहिए था, इसलिए मैंने खुद एक बना लिया। यह simple और fast है, और अपने उद्देश्य के लिए अच्छी तरह काम करता है

  • SHA1 से बाहर निकलने का बदलाव बहुत ज़्यादा समय ले रहा है
    hash function को शुरू से ही ज़्यादा modular structure के साथ डिज़ाइन किया जाना चाहिए था

  • मुझे लगता है Git में commit स्तर पर software license tracking की सुविधा होनी चाहिए

    • आपका मतलब पूरी तरह समझ नहीं आया, लेकिन यह Git का काम नहीं है। Git सिर्फ एक source code management system है, और अतिरिक्त सुविधाएँ git-annex जैसे extension tools के ज़रिए लागू होनी चाहिए
    • अगर Git में ऐसी सुविधा होगी, तो वह उल्टा बदतर हो जाएगा। commits में पहले से arbitrary data स्टोर किया जा सकता है, इसलिए ज़रूरी metadata बस commit में डालिए और अलग tool से उसे प्रोसेस कीजिए
    • LLM-assisted code की तरह trailers का इस्तेमाल किया जा सकता है
      उदाहरण: Co-Authored-By: Whatever LLM, License: WTFPL