- दुनिया भर के डेवलपर्स द्वारा इस्तेमाल किया जाने वाला 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 पर काम जारी है
अभी कोई टिप्पणी नहीं है.