Git: ते का जिंकले, आणि कुठे चुकते

चौऱ्याण्णव टक्के डेव्हलपर Git वापरतात [6]. उर्वरित सहा टक्के बहुतेक विशेष उद्योगांमध्ये आहेत — गेम स्टुडिओ, मोठ्या वित्त कंपन्या — आणि तेही हळूहळू स्थलांतर करत आहेत. प्रत्येक इतर व्हर्जन कंट्रोल सिस्टम एकतर मृत झाली आहे, मरणासन्न अवस्थेत आहे, किंवा केवळ एखाद्या कोपऱ्यात टिकून आहे. एका व्यक्तीने सुमारे दोन आठवड्यांत लिहिलेल्या सॉफ्टवेअरसाठी हा एक विचित्र परिणाम आहे.

या सर्वाची सुरुवात करणारी BitKeeper घटना

Git कुणाला बसून “चला परिपूर्ण व्हर्जन कंट्रोल सिस्टम डिझाइन करूया” असा विचार आल्यामुळे उदयास आली नाही. ती उदयास आली कारण कुणीतरी एक मोफत परवाना काढून घेतला.

Linux kernel — आजवर बांधलेल्या सर्वात गुंतागुंतीच्या सहयोगी सॉफ्टवेअर प्रकल्पांपैकी एक — BitKeeper, एक मालकीची distributed VCS, मोफत वापरत होता. 2005 मध्ये, ओपन-सोर्स समुदायाशी वादानंतर BitKeeper च्या मालकाने तो मोफत परवाना रद्द केला [2]. Linus Torvalds विद्यमान पर्यायांकडे परत जाऊ शकत नव्हते. CVS आणि SVN Linux च्या प्रमाणासाठी खूप मंद आणि खूप केंद्रीकृत होते. Mercurial समांतरपणे विकसित होत होती पण तयार नव्हती.

म्हणून Torvalds सुमारे दहा दिवसांसाठी ऑफलाइन गेले आणि Git शून्यापासून लिहिली [2].

हीच उत्पत्तीची कहाणी आहे. प्रेरणा नाही, गरज होती. खरे तर, राग होता.

Git खरोखर काय आहे

Git एक distributed version control system आहे. तो एकच शब्द — distributed — हेच त्याला आधी आलेल्या सर्व गोष्टींपासून वेगळे करतो.

CVS आणि SVN सारख्या जुन्या प्रणालींमध्ये, एक केंद्रीय सर्व्हर असतो. प्रत्येक डेव्हलपर commit करण्यासाठी, इतिहास पाहण्यासाठी, कोणतीही अर्थपूर्ण गोष्ट करण्यासाठी त्याच्याशी कनेक्ट होतो [3]. जर तो सर्व्हर डाउन झाला, तर तुम्ही अडकलात. जर तुम्ही विमानात असाल, तर तुम्ही अडकलात. नेटवर्क मंद असेल तर काय होते ते तुम्हाला आधीच माहीत आहे.

Git सह, प्रत्येक डेव्हलपरकडे संपूर्ण repository ची पूर्ण प्रत असते — संपूर्ण इतिहास, सर्व branches, प्रत्येक एकल commit — त्यांच्या मशीनवर स्थानिकरित्या [3]. तुम्ही स्थानिकरित्या commit करता. स्थानिकरित्या branch करता. स्थानिकरित्या diff करता. नेटवर्क तेव्हाच समाविष्ट होते जेव्हा तुम्हाला इतरांसोबत बदल शेअर करायचे असतात.

हे एक किरकोळ वास्तुशास्त्रीय निर्णय वाटते. तसे नाही. ते विकासाबद्दल तुम्ही कसे विचार करता ते पूर्णपणे बदलते.

काही गोष्टी ज्या Git तांत्रिकदृष्ट्या खरोखर बरोबर करते:

Branching स्वस्त आहे. SVN मध्ये, branching संपूर्ण directory कॉपी करते — मंद आणि महाग. Git मध्ये, एक branch फक्त एक commit कडे निर्देशक आहे, त्यामुळे एक तयार करणे किंवा हटवणे मूलत: मोफत आहे [5].
Merging खरोखर काम करते. Git प्रत्येक commit च्या अचूक पूर्वजांचा मागोवा घेते, त्यामुळे जेव्हा दोन branches वेगळ्या होतात तेव्हा ते सामान्य आधाराच्या सापेक्ष काय बदलले ते जाणते. SVN चे merging कुप्रसिद्धपणे वेदनादायक होते [5].
SHA-1 content hashing. प्रत्येक फाइल, commit, आणि tree त्याच्या सामग्रीच्या क्रिप्टोग्राफिक hash द्वारे ओळखली जाते [1]. तुम्ही डेटा शांतपणे दूषित करू शकत नाही — Git ते शोधेल.
डिझाइनने वेगवान. बहुतेक ऑपरेशन्स — log, diff, commit, branch switch — स्थानिक आहेत आणि म्हणून वेगवान आहेत. Git पहिल्या दिवसापासून Linux kernel च्या आकाराच्या प्रकल्पासाठी बांधली गेली [2].

केंद्रीकृत विरुद्ध वितरित vcs

SVN, Mercurial, CVS, आणि Perforce का हरले

CVS — 1980 च्या दशकात बांधलेले — atomic commits देखील समर्थित करत नाही [6]. जर तुमचे commit अर्धवट क्रॅश झाले, तर repository एका तुटलेल्या असंगत अवस्थेत सोडली जाते. त्याला खरे rename समर्थन देखील नाही. CVS Git ने इतके हारले नाही जितके Git अस्तित्वात येण्यापूर्वीच ते मरत होते.

SVN ने CVS च्या बहुतेक समस्या दुरुस्त केल्या आणि काही काळासाठी खरोखरच प्रबळ होते. परंतु ते केंद्रीकृत आहे, branching महाग आहे, आणि ऑफलाइन काम गंभीरपणे मर्यादित आहे [6]. जसजसे विकास संघ distributed मॉडेल्सकडे स्थलांतरित झाले — खंडभर ओपन-सोर्स योगदानकर्ते, अनेक स्वतंत्र microservice संघ, remote-first संघटना — SVN च्या गृहितकांमुळे त्रास होऊ लागला. 2025 पर्यंत, SVN बहुतेक legacy enterprise codebase मध्ये आढळते जे कोणालाही स्पर्श करायचे नाही [6].

Mercurial ही सर्वात मनोरंजक कहाणी आहे आणि जी Git चाहत्यांना किमान थोडे नम्र करायला हवी. Mercurial Git च्या त्याच वर्षी लॉन्च झाले, BitKeeper घटनेला प्रतिसाद म्हणून [2]. ते वापरण्यास तर्कसंगतपणे सोपे आहे, आणि त्याचे CLI अधिक सुसंगत आहे. परंतु Bitbucket ने 2020 मध्ये Mercurial समर्थन सोडले, जे प्रभावीपणे मृत्युदंडाची शिक्षा होती [6]. एका मोठ्या होस्टिंग प्लॅटफॉर्मशिवाय, Mercurial कडे कोणताही नेटवर्क इफेक्ट नव्हता. आज ते अंदाजे 2% मार्केट शेअरवर आहे [6].

Perforce (Helix Core) हा एकमेव गंभीर पर्याय आहे जो अजूनही जिवंत आहे — परंतु केवळ विशिष्ट क्षेत्रांमध्ये: गेम डेव्हलपमेंट, वित्त, नियमित enterprise. ते Git पेक्षा मोठ्या binary फाइल्स चांगल्या प्रकारे हाताळते आणि केंद्रीकृत access controls आहेत जे काही enterprises ला आवश्यक आहेत. ते महाग, मालकीचे आहे आणि वेगाने कुठेही जात नाही.

प्रणाली	वास्तुकला	Branching	ऑफलाइन काम	मार्केट शेअर 2025
Git	Distributed	स्वस्त, तात्काळ	पूर्ण	~94%
SVN	Centralized	महाग	खूप मर्यादित	~5%
Mercurial	Distributed	चांगले	पूर्ण	~2%
CVS	Centralized	वेदनादायक	काहीही नाही	मूलत: मृत
Perforce	Centralized	मध्यम	मर्यादित	Niche (गेम्स/enterprise)

GitHub ने विजय कायमचा केला

Git तांत्रिक गुणवत्तेवर जिंकले. GitHub ने ते अपरिवर्तनीय केले.

GitHub 2007 मध्ये लॉन्च झाले, Git नंतर फक्त दोन वर्षांनी [1]. त्याने Git ला एक सामाजिक स्तर दिला — pull requests, forks, code review, issue tracking. ओपन-सोर्स प्रकल्प तिथे गेले. कंपन्या त्याचे अनुसरण केले. मग संपूर्ण ecosystem त्याचे अनुसरण केले. CI/CD टूल्सनी GitHub गृहीत धरले. Hiring pipelines ने GitHub profiles चा संदर्भ दिला. Package registries GitHub repos शी जोडल्या.

Bitbucket आणि GitLab ने स्पर्धा करण्याचा प्रयत्न केला तेव्हा, GitHub कडे नेटवर्क इफेक्ट्स होते जे मूलत: अभेद्य होते. GitHub अस्तित्वात आल्यावर Mercurial तांत्रिकदृष्ट्या तुलनात्मक असणे महत्त्वाचे नव्हते. प्लॅटफॉर्मने टूलला गिळंकृत केले.

2025 Stack Overflow Developer Survey GitHub ला डेव्हलपर्समध्ये 81% वापरासह प्रमुख सहयोग प्लॅटफॉर्म म्हणून दर्शवतो [11].

Git बद्दल खरोखर वाईट काय आहे

हा तो भाग आहे जो बहुतेक tutorials वगळतात, किंवा “Git शिकण्यास कठीण आहे” एका ओळीत म्हणून पुढे जातात.

CLI असंगततेची एक आपत्ती आहे. git checkout branches बदलणे आणि फाइल बदल टाकून देणे दोन्ही हाताळायचे — दोन पूर्णपणे असंबंधित ऑपरेशन्स, एक कमांड. त्यांना शेवटी ते git switch आणि git restore मध्ये विभाजित करावे लागले [9]. Error messages अनेकदा गूढ असतात. “Detached HEAD state” वर्षानुवर्षे Git वापरणाऱ्या लोकांना गोंधळवते. rebase vs merge vs cherry-pick समजून घेण्यासाठी आवश्यक मानसिक मॉडेल खरोखरच क्षुल्लक नाही.

Binary files ही एक खरी वास्तुशास्त्रीय विसंगती आहे. Git प्रत्येक फाइलच्या प्रत्येक आवृत्तीची संपूर्ण सामग्री संग्रहित करते. Text files सुंदरपणे compress आणि delta-encode होतात. 100MB Photoshop फाइल किंवा गेम asset तसे होत नाही [9]. मोठ्या binary-heavy repos आकारात लवकर फुगतात. हेच खरे कारण आहे की गेम स्टुडिओ Perforce शी राहतात — प्राधान्य नाही, परंतु Git च्या डिझाइन आणि त्यांच्या डेटा यांच्यातील मूलभूत विसंगती. Git LFS एक उपाय म्हणून अस्तित्वात आहे, परंतु ते ऑपरेशनल गुंतागुंत जोडते आणि समस्या पूर्णपणे सोडवत नाही.

Monorepos मोठ्या प्रमाणावर तुटतात. लाखो फाइल्ससह प्रचंड codebase चालवणाऱ्या कंपन्यांना आढळते की Git खराब होते. 9GB repo वर एकच git pull सहा मिनिटे घेऊ शकते [9]. Microsoft ला Windows source development Git मध्ये व्यवहार्य करण्यासाठी स्वतःचा virtual filesystem layer (VFS for Git, आता Scalar) बांधावा लागला. हे scalability चे जोरदार समर्थन नाही.

“distributed” वास्तुकला व्यवहारात केंद्रीकृत झाली. Git peer-to-peer डिझाइन केले गेले होते. वास्तवात, प्रत्येक संघ GitHub वर push करतो, ज्याला मागील 12 महिन्यांत 48 मोठे outages झाले आहेत — मे 2025 ते एप्रिल 2026 दरम्यान 257 एकूण घटनांसह, दर आठवड्याला अंदाजे एक महत्त्वपूर्ण व्यत्यय [10]. distributed डिझाइन कोणतीही वास्तविक-जगातील लवचिकता प्रदान करत नाही जेव्हा प्रत्येकाचे workflow एका सेवेच्या बंद पडण्यामुळे अवरोधित होते.

AI-generated कोड Git च्या गृहितकांवर कठोरपणे ताण देत आहे. GitHub ने 2025 मध्ये AI-generated projects मध्ये वर्ष-दर-वर्ष 206% वाढ पाहिली [10], आणि AI agents त्या प्रमाणात आणि वारंवारतेने commit करतात जे मानवांनी कधीही केले नाही. Git चे merge conflict model, pull request workflow, आणि history semantics मानव गतीने कोड वाचणाऱ्या आणि लिहिणाऱ्या मानवांसाठी डिझाइन केले गेले होते. The Register ने मे 2026 मध्ये नोंदवले की “Git is unprepared for the AI coding tsunami” [8] — आणि Git सध्या automated commits च्या या प्रमाणाला कसे हाताळते ते पाहता, ते मूल्यांकन वाद घालणे कठीण आहे.

Git जिंकले कारण ते योग्य वेळी योग्य साधन होते, योग्य प्रकल्पाशी जोडलेले होते, आणि नंतर योग्य प्लॅटफॉर्मने लॉक इन केले. ते अजूनही बहुतेक वेळ बहुतेक गोष्टींसाठी योग्य साधन आहे. ते 20 वर्षे जुने डिझाइन देखील आहे जे अशा समस्यांसाठी बांधले गेले होते जे आता लक्षणीयरीत्या बदलल्या आहेत.

समाप्त