Git: यह क्यों जीता, और यह क्या गलत करता है

94% डेवलपर Git का उपयोग करते हैं [6]। शेष छह प्रतिशत ज़्यादातर विशेष उद्योगों में हैं — गेम स्टूडियो, बड़ी वित्त कंपनियां — और वे भी धीरे-धीरे माइग्रेट हो रहे हैं। हर दूसरी संस्करण नियंत्रण प्रणाली या तो मर चुकी है, अंतिम सांसें ले रही है, या केवल एक कोने की जगह में जीवित है। यह एक अजीब परिणाम है उस सॉफ़्टवेयर के लिए जिसे एक व्यक्ति ने लगभग दो हफ्तों में लिखा था।

वह BitKeeper घटना जिसने यह सब शुरू किया

Git इसलिए नहीं आया क्योंकि किसी ने बैठकर सोचा “मैं परफेक्ट वर्शन कंट्रोल सिस्टम डिज़ाइन करूंगा।” यह इसलिए आया क्योंकि किसी ने एक मुफ्त लाइसेंस छीन लिया।

Linux कर्नेल — अब तक बना सबसे जटिल सहयोगी सॉफ़्टवेयर प्रोजेक्टों में से एक — मुफ़्त में BitKeeper, एक मालिकाना वितरित VCS, का उपयोग कर रहा था। 2005 में, ओपन-सोर्स समुदाय के साथ विवाद के बाद BitKeeper के मालिक ने वह मुफ्त लाइसेंस रद्द कर दिया [2]। Linus Torvalds मौजूदा विकल्पों पर वापस नहीं जा सकते थे। CVS और SVN Linux के पैमाने के लिए बहुत धीमे और बहुत केंद्रीकृत थे। Mercurial समानांतर में विकसित हो रहा था लेकिन तैयार नहीं था।

तो Torvalds लगभग दस दिनों के लिए ऑफलाइन हो गए और Git को स्क्रैच से लिखा [2]।

यही उत्पत्ति की कहानी है। ज़रूरत, प्रेरणा नहीं। वास्तव में, गुस्सा।

Git वास्तव में क्या है

Git एक वितरित संस्करण नियंत्रण प्रणाली है। वह एक शब्द — वितरित — यही है जो इसे पहले आई हर चीज़ से अलग करता है।

CVS और SVN जैसी पुरानी प्रणालियों में, एक केंद्रीय सर्वर होता है। हर डेवलपर कमिट करने के लिए, इतिहास देखने के लिए, कुछ भी सार्थक करने के लिए उससे जुड़ता है [3]। अगर वह सर्वर बंद हो जाए, तो आप फंस जाते हैं। अगर आप फ्लाइट पर हैं, तो आप फंस जाते हैं। अगर नेटवर्क धीमा है, तो आप पहले से जानते हैं कि क्या होगा।

Git के साथ, हर डेवलपर के पास पूरी रिपॉज़िटरी की एक संपूर्ण कॉपी होती है — पूरा इतिहास, सभी शाखाएं, हर एक कमिट — अपनी मशीन पर स्थानीय रूप से [3]। आप स्थानीय रूप से कमिट करते हैं। आप स्थानीय रूप से ब्रांच करते हैं। आप स्थानीय रूप से diff करते हैं। नेटवर्क तभी शामिल होता है जब आप दूसरों के साथ परिवर्तन साझा करना चाहते हैं।

यह एक मामूली आर्किटेक्चरल विकल्प की तरह लगता है। यह नहीं है। यह पूरी तरह से बदल देता है कि आप विकास के बारे में कैसे सोचते हैं।

कुछ चीजें जो Git तकनीकी रूप से वास्तव में सही करता है:

ब्रांचिंग सस्ती है। SVN में, ब्रांचिंग पूरी डायरेक्टरी कॉपी करती है — धीमी और महंगी। Git में, एक ब्रांच सिर्फ एक कमिट की ओर एक पॉइंटर है, इसलिए एक बनाना या हटाना अनिवार्य रूप से मुफ्त है [5]।
मर्जिंग वास्तव में काम करती है। Git हर कमिट के सटीक पूर्वजों को ट्रैक करता है, इसलिए जब दो शाखाएं अलग होती हैं तो यह जानता है कि सामान्य आधार के सापेक्ष क्या बदला। SVN की मर्जिंग कुख्यात रूप से कठिन थी [5]।
SHA-1 कंटेंट हैशिंग। हर फ़ाइल, कमिट, और ट्री को उसके कंटेंट के क्रिप्टोग्राफिक हैश द्वारा पहचाना जाता है [1]। आप डेटा को चुपचाप खराब नहीं कर सकते — Git इसे डिटेक्ट करेगा।
डिज़ाइन द्वारा गति। अधिकांश ऑपरेशन — log, diff, commit, branch switch — स्थानीय हैं और इसलिए तेज़। Git को पहले दिन से Linux कर्नेल के आकार के प्रोजेक्ट के लिए बनाया गया था [2]।

केंद्रीकृत बनाम वितरित vcs

SVN, Mercurial, CVS, और Perforce क्यों हारे

CVS — 1980 के दशक में बना — परमाणु कमिट का भी समर्थन नहीं करता [6]। अगर आपका कमिट आधे रास्ते में क्रैश हो जाता है, तो रिपॉज़िटरी टूटी हुई असंगत स्थिति में छोड़ दी जाती है। इसमें वास्तविक रिनेम समर्थन भी नहीं है। CVS को Git ने इतना नहीं हराया जितना कि वह Git के अस्तित्व में आने से पहले ही मर रहा था।

SVN ने CVS की अधिकांश समस्याओं को ठीक किया और कुछ समय के लिए वास्तव में प्रमुख था। लेकिन यह केंद्रीकृत है, ब्रांचिंग महंगी है, और ऑफलाइन काम बहुत सीमित है [6]। जैसे-जैसे डेवलपमेंट टीमें वितरित मॉडल की ओर स्थानांतरित हुईं — महाद्वीपों भर में ओपन-सोर्स योगदानकर्ता, कई स्वतंत्र माइक्रोसर्विस टीमें, रिमोट-फर्स्ट संगठन — SVN की धारणाएं दर्दनाक होने लगीं। 2025 तक, SVN ज़्यादातर उन लीगेसी एंटरप्राइज़ कोडबेस में पाया जाता है जिन्हें कोई छूना नहीं चाहता [6]।

Mercurial सबसे दिलचस्प कहानी है और जो Git प्रशंसकों को कम से कम थोड़ा विनम्र बनानी चाहिए। Mercurial उसी साल लॉन्च हुआ जब Git, भी BitKeeper घटना के जवाब में [2]। यह तर्कतः उपयोग में आसान है, और इसका CLI अधिक सुसंगत है। लेकिन Bitbucket ने 2020 में Mercurial समर्थन हटा दिया, जो प्रभावी रूप से मृत्युदंड था [6]। एक प्रमुख होस्टिंग प्लेटफ़ॉर्म के बिना, Mercurial का कोई नेटवर्क प्रभाव नहीं था। आज यह लगभग 2% बाज़ार हिस्सेदारी पर बैठता है [6]।

Perforce (Helix Core) एकमात्र गंभीर विकल्प है जो अभी भी जीवित है — लेकिन केवल विशिष्ट क्षेत्रों में: गेम डेवलपमेंट, वित्त, विनियमित एंटरप्राइज़। यह Git से बेहतर बड़ी बाइनरी फ़ाइलों को संभालता है और केंद्रीकृत एक्सेस कंट्रोल है जो कुछ एंटरप्राइज़ को चाहिए। यह महंगा है, मालिकाना है, और कहीं तेज़ी से नहीं जा रहा।

सिस्टम	आर्किटेक्चर	ब्रांचिंग	ऑफलाइन काम	2025 बाज़ार हिस्सेदारी
Git	वितरित	सस्ती, तत्काल	पूर्ण	~94%
SVN	केंद्रीकृत	महंगी	बहुत सीमित	~5%
Mercurial	वितरित	अच्छी	पूर्ण	~2%
CVS	केंद्रीकृत	कठिन	कोई नहीं	अनिवार्य रूप से मृत
Perforce	केंद्रीकृत	मध्यम	सीमित	निच (गेम्स/एंटरप्राइज़)

GitHub ने जीत को स्थायी बना दिया

Git तकनीकी योग्यता पर जीता। GitHub ने इसे अपरिवर्तनीय बना दिया।

GitHub 2007 में लॉन्च हुआ, Git के सिर्फ दो साल बाद [1]। इसने Git को एक सामाजिक परत दी — पुल रिक्वेस्ट, फोर्क, कोड रिव्यू, इशू ट्रैकिंग। ओपन-सोर्स प्रोजेक्ट वहां गए। कंपनियां आईं। फिर पूरा इकोसिस्टम आया। CI/CD टूल्स ने GitHub मान लिया। हायरिंग पाइपलाइन ने GitHub प्रोफाइल का संदर्भ दिया। पैकेज रजिस्ट्री ने GitHub रेपो से लिंक किया।

जब तक Bitbucket और GitLab ने प्रतिस्पर्धा करने की कोशिश की, GitHub के नेटवर्क प्रभाव अनिवार्य रूप से अजेय थे। Mercurial का तकनीकी रूप से तुलनीय होना एक बार GitHub के अस्तित्व में आने के बाद कोई मायने नहीं रखता था। प्लेटफ़ॉर्म ने टूल को खा लिया।

2025 Stack Overflow डेवलपर सर्वे GitHub को डेवलपर्स के बीच 81% उपयोग पर प्रमुख सहयोग प्लेटफ़ॉर्म के रूप में दिखाता है [11]।

Git के बारे में वास्तव में क्या बुरा है

यहां वह हिस्सा है जो अधिकांश ट्यूटोरियल छोड़ते हैं, या “Git में सीखने की कड़ी ढाल है” की एक पंक्ति लिखकर आगे बढ़ जाते हैं।

CLI असंगतता की आपदा है। git checkout ब्रांच स्विच करने और फ़ाइल परिवर्तनों को त्यागने दोनों को संभालता था — दो पूरी तरह से असंबंधित ऑपरेशन, एक कमांड। उन्हें अंततः इसे git switch और git restore में विभाजित करना पड़ा [9]। एरर मैसेज अक्सर क्रिप्टिक होते हैं। “Detached HEAD state” उन लोगों को भ्रमित करता है जो वर्षों से Git का उपयोग कर रहे हैं। rebase बनाम merge बनाम cherry-pick को समझने के लिए आवश्यक मानसिक मॉडल वास्तव में गैर-तुच्छ है।

बाइनरी फ़ाइलें एक वास्तविक आर्किटेक्चरल बेमेल हैं। Git हर फ़ाइल के हर संस्करण की पूरी सामग्री स्टोर करता है। टेक्स्ट फ़ाइलें सुंदर ढंग से संपीड़ित और डेल्टा-एनकोड होती हैं। एक 100MB Photoshop फ़ाइल या एक गेम एसेट नहीं होती [9]। बड़े बाइनरी-भारी रेपो तेज़ी से आकार में बढ़ते हैं। यही वास्तविक कारण है कि गेम स्टूडियो Perforce के साथ रहते हैं — पसंद नहीं, बल्कि Git के डिज़ाइन और उनके डेटा के बीच एक मौलिक बेमेल। Git LFS एक वर्कअराउंड के रूप में मौजूद है, लेकिन यह परिचालन जटिलता जोड़ता है और पूरी तरह से समस्या हल नहीं करता।

मोनोरेपो बड़े पैमाने पर टूट जाते हैं। लाखों फ़ाइलों के साथ विशाल कोडबेस चलाने वाली कंपनियां पाती हैं कि Git बुरी तरह खराब हो जाता है। एक 9GB रेपो पर एक git pull छह मिनट ले सकता है [9]। Microsoft को अपनी खुद की वर्चुअल फाइलसिस्टम लेयर (VFS for Git, अब Scalar) बनानी पड़ी, बस Git में Windows सोर्स डेवलपमेंट को व्यवहार्य बनाने के लिए। यह स्केलेबिलिटी का कोई उत्साहजनक समर्थन नहीं है।

“वितरित” आर्किटेक्चर व्यवहार में केंद्रीकृत हो गया। Git को पीयर-टू-पीयर डिज़ाइन किया गया था। वास्तव में, हर टीम GitHub पर पुश करती है, जिसमें पिछले 12 महीनों में 48 प्रमुख आउटेज हुए हैं — लगभग प्रति सप्ताह एक महत्वपूर्ण व्यवधान, मई 2025 और अप्रैल 2026 के बीच कुल 257 घटनाएं [10]। वितरित डिज़ाइन कोई वास्तविक-दुनिया लचीलापन प्रदान नहीं करता जब हर किसी का वर्कफ़्लो एक सेवा के बंद होने से अवरुद्ध हो जाता है।

AI-जनरेटेड कोड Git की धारणाओं पर कठोरता से दबाव डाल रहा है। GitHub ने 2025 में AI-जनरेटेड प्रोजेक्ट में साल-दर-साल 206% वृद्धि देखी [10], और AI एजेंट उस मात्रा और आवृत्ति पर कमिट करते हैं जो मनुष्यों ने कभी नहीं की। Git का मर्ज कॉन्फ्लिक्ट मॉडल, पुल रिक्वेस्ट वर्कफ़्लो, और इतिहास की अर्थशास्त्र मानव गति से कोड पढ़ने और लिखने वाले मनुष्यों के लिए डिज़ाइन किए गए थे। The Register ने मई 2026 में रिपोर्ट किया कि “Git AI कोडिंग सुनामी के लिए तैयार नहीं है” [8] — और यह देखते हुए कि Git वर्तमान में इस मात्रा के स्वचालित कमिट को कैसे संभालता है, उस आकलन से बहस करना मुश्किल है।

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

समाप्त