मोबाइल डेवलपमेंट में Git और संस्करण नियंत्रण: यह क्या है, बुनियादी कमांड और यह कैसे काम करता है

संस्करण नियंत्रण और Git: यह क्या है?

Git एक वितरित संस्करण नियंत्रण प्रणाली (VCS) है जिसे लिनस टॉर्वाल्ड्स ने 2005 में लिनक्स कर्नेल डेवलपमेंट के लिए बनाया था। केंद्रीकृत प्रणालियों (SVN, CVS) के विपरीत, Git प्रत्येक डेवलपर के कंप्यूटर पर प्रोजेक्ट इतिहास की पूरी प्रतिलिपि संग्रहीत करता है। इसका मतलब है कि आप इंटरनेट कनेक्शन के बिना भी कमिट कर सकते हैं, इतिहास देख सकते हैं और शाखाएँ बना सकते हैं।

Git स्नैपशॉट के साथ काम करता है — प्रत्येक कमिट सहेजने के समय सभी प्रोजेक्ट फ़ाइलों की स्थिति को सहेजता है। यदि फ़ाइल नहीं बदली है, तो Git पिछले संस्करण का संदर्भ बनाता है, जिससे स्थान बचता है। GitHub विश्लेषण (2025) के अनुसार, औसत रिपॉजिटरी में 1,200 कमिट और 15 शाखाएँ होती हैं।

IT Sectr में, हम 2017 से सभी प्रोजेक्ट्स में Git का उपयोग कर रहे हैं। हमारा अनुभव दिखाता है कि पहले दिन से उचित Git कॉन्फ़िगरेशन टीम को मर्ज और विरोध समाधान पर 30% तक समय बचाता है। Git डी-फैक्टो मानक बन गया है — यह सभी आधुनिक IDE (Android Studio, Xcode, VS Code) और CI/CD सिस्टम द्वारा समर्थित है।

# बुनियादी Git सेटअप
git config --global user.name "आपका नाम"
git config --global user.email "your@email.com"

# नई रिपॉजिटरी बनाना
git init my-project
cd my-project

# फ़ाइलें जोड़ना और कमिट करना
git add README.md
git commit -m "Initial commit"

# दूरस्थ रिपॉजिटरी के साथ काम करना
git remote add origin https://github.com/user/my-project.git
git push -u origin main

उपरोक्त कोड मूल अनुक्रम दिखाता है: रिपॉजिटरी को आरंभ करना, पहला कमिट, और दूरस्थ सर्वर पर प्रकाशन। git init कमांड एक छिपा हुआ .git फ़ोल्डर बनाता है जो संपूर्ण प्रोजेक्ट इतिहास संग्रहीत करेगा। प्रत्येक git commit एक पुनर्स्थापना बिंदु बनाता है जिस पर आप किसी भी समय वापस लौट सकते हैं।

बुनियादी अवधारणाएँ: Repository, Branch, Commit

तीन बुनियादी अवधारणाओं — Repository, Branch, और Commit — को समझना किसी भी संस्करण नियंत्रण प्रणाली के साथ काम करने के लिए आवश्यक है। रिपॉजिटरी पूरे प्रोजेक्ट के लिए एक कंटेनर है। Commit फ़ाइलों की सहेजी गई स्थिति है। Branch विकास की एक अलग रेखा है।

Repository (रिपॉजिटरी) स्थानीय (आपके कंप्यूटर पर) या दूरस्थ (GitHub, GitLab सर्वर पर) हो सकती है। प्रत्येक डेवलपर दूरस्थ रिपॉजिटरी को अपनी मशीन पर क्लोन करता है और स्थानीय प्रतिलिपि के साथ काम करता है। परिवर्तन push (भेजना) और pull (लाना) के माध्यम से सिंक्रनाइज़ किए जाते हैं। वितरित संस्करण नियंत्रण में, प्रत्येक डेवलपर इतिहास की पूरी प्रतिलिपि संग्रहीत करता है।

Branch (शाखा) एक कमिट की ओर इशारा करने वाला संकेतक है। शाखाएँ समानांतर विकास की अनुमति देती हैं: एक डेवलपर नई सुविधा पर काम करता है (feature branch), दूसरा बग ठीक करता है (hotfix branch), तीसरा रिलीज़ तैयार करता है (release branch)। GitLab Flow (2025) के अनुसार, औसत प्रोजेक्ट में एक साथ 3–5 सक्रिय शाखाएँ होती हैं।

Commit (कमिट) परिवर्तन की एक इकाई है। प्रत्येक कमिट में एक अद्वितीय हैश (SHA-1), संदेश, लेखक और समय टिकट होता है। अच्छा अभ्यास छोटे सार्थक कमिट वर्णनात्मक संदेशों के साथ करना है — यह कोड समीक्षा और परिवर्तनों को वापस लाने को सरल बनाता है। कमिट के माध्यम से संस्करण नियंत्रण आपको पूर्ण प्रोजेक्ट इतिहास देता है।

Feature Branch

Feature Branch (सुविधा शाखा) एक अस्थायी शाखा है जो किसी विशिष्ट कार्य के विकास के लिए develop या main से बनाई जाती है। काम पूरा होने के बाद, शाखा को Pull Request के माध्यम से वापस मर्ज किया जाता है और हटा दिया जाता है। यह अभ्यास मुख्य कोडबेस की स्थिरता को बाधित किए बिना परिवर्तनों को अलग करने की अनुमति देता है।

सामान्य कार्यप्रवाह: शाखा बनाएँ feature/add-login → कई कमिट करें → Pull Request बनाएँ → कोड समीक्षा से गुज़रें → develop में मर्ज करें। IT Sectr में हम बिल्कुल इसी दृष्टिकोण का उपयोग करते हैं: प्रत्येक Jira कार्य एक अलग feature शाखा से मेल खाता है। यह परिवर्तनों की ट्रैकिंग और ज़रूरत पड़ने पर वापस लाने को सरल बनाता है।

Rebase बनाम Merge

Merge एक मर्ज कमिट बनाता है जो दो शाखाओं को जोड़ता है। यह समानांतर विकास रेखाओं सहित पूर्ण इतिहास को संरक्षित करता है। Rebase इतिहास को फिर से लिखता है: यह एक शाखा से कमिट लेता है और उन्हें दूसरी शाखा के ऊपर "पुनः लागू" करता है, एक रैखिक इतिहास बनाता है।

Merge सार्वजनिक शाखाओं और बड़ी टीमों के लिए बेहतर उपयुक्त है जहाँ कालक्रम महत्वपूर्ण है। Rebase PR बनाने से पहले व्यक्तिगत feature शाखाओं के लिए सुविधाजनक है — यह इतिहास को साफ और अधिक समझने योग्य बनाता है। हालाँकि, rebase को उन शाखाओं पर कभी लागू नहीं किया जाना चाहिए जिन पर अन्य डेवलपर्स काम कर रहे हैं, क्योंकि यह इतिहास को फिर से लिखता है।

# फीचर शाखा बनाना और उस पर स्विच करना
git checkout -b feature/add-login main

# शाखा में काम करना
git add login-screen/
git commit -m "Add login screen layout"

# PR से पहले नवीनतम main पर Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# दूरस्थ रिपॉजिटरी में Push
git push origin feature/add-login

यह उदाहरण एक सामान्य कार्यप्रवाह दिखाता है: main से फीचर शाखा बनाना, कई कमिट, और समीक्षा के लिए भेजने से पहले साफ रैखिक इतिहास पाने के लिए rebase। यह दृष्टिकोण मर्ज विरोध को कम करता है।

Git Flow बनाम Trunk-Based Development

Git Flow और Trunk-Based Development दो मुख्य संस्करण नियंत्रण रणनीतियाँ हैं जो यह निर्धारित करती हैं कि टीम Git के साथ काम को कैसे व्यवस्थित करती है। चुनाव टीम के आकार, रिलीज़ आवृत्ति और स्थिरता आवश्यकताओं पर निर्भर करता है।

Git Flow कई स्थायी शाखाओं वाला एक सख्त मॉडल है: main (रिलीज़ कोड), develop (वर्तमान विकास), feature/* (नई सुविधाएँ), release/* (रिलीज़ तैयारी) और hotfix/* ( urgent fixes)। यह मॉडल स्पष्ट रिलीज़ चक्र वाली परियोजनाओं के लिए अच्छा है (जैसे, संस्करण 1.0, 2.0 वाले मोबाइल ऐप)।

Trunk-Based Development एक एकल मुख्य शाखा (trunk/main) वाला दृष्टिकोण है जहाँ सभी डेवलपर्स दिन में कई बार परिवर्तन मर्ज करते हैं। अधूरी सुविधाओं को छिपाने के लिए फीचर फ़्लैग का उपयोग किया जाता है। यह दृष्टिकोण वेब डेवलपमेंट और स्टार्टअप में लोकप्रिय है जहाँ डिलीवरी की गति मायने रखती है।

Git Flow

Git Flow, जिसे विंसेंट ड्रिसन ने 2010 में प्रस्तावित किया था, सबसे लोकप्रिय मॉडलों में से एक बना हुआ है। इसका मुख्य लाभ जीवनचक्र चरणों द्वारा कोड का सख्त पृथक्करण है। main शाखा में केवल रिलीज़ कोड होता है, develop में वर्तमान विकास होता है, और फीचर शाखाएँ नई सुविधाओं को एक-दूसरे से अलग करती हैं।

Hotfix शाखाएँ urgent fixes के लिए main से बनाई जाती हैं और मर्ज करने के बाद main और develop दोनों में वापस मर्ज की जाती हैं। Release शाखाएँ develop से बनाई जाती हैं जब टीम रिलीज़ के लिए तैयार होती है। उनमें केवल बग फिक्स और मेटाडेटा (संस्करण, बिल्ड) जोड़े जाते हैं। रिलीज़ के बाद, release शाखा main और develop में मर्ज की जाती है। JetBrains सर्वेक्षण (2024) के अनुसार, 37% टीमें Git Flow का उपयोग करती हैं। यह संस्करण नियंत्रण मॉडल निश्चित रिलीज़ वाली परियोजनाओं के लिए मानक बना हुआ है।

# Git Flow उदाहरण: रिलीज़ पर काम शुरू करना
git checkout -b release/1.2.0 develop

# release शाखा में बग ठीक करना
git commit -m "Fix login button crash"

# रिलीज़ पूरी करना — main और develop में मर्ज करें
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# release शाखा हटाना
git branch -d release/1.2.0

कोड release शाखा बनाने, उसे स्थिर करने और मुख्य शाखाओं में मर्ज करने का वर्णन करता है। --no-ff फ़्लैग मर्ज कमिट की गारंटी देता है, जो जानकारी संरक्षित करता है कि परिवर्तन release शाखा से आए हैं।

Pull Request और कोड समीक्षा

Pull Request (PR) एक तंत्र है जिसके द्वारा एक डेवलपर अपनी शाखा से मुख्य शाखा में परिवर्तन प्रस्तावित करता है। PR टीम वर्क में संस्करण नियंत्रण का एक प्रमुख तत्व है — यह केवल कोड मर्ज करने का तरीका नहीं है, बल्कि चर्चा, समीक्षा और गुणवत्ता जांच की प्रक्रिया है। GitLab में, समान तंत्र को Merge Request (MR) कहा जाता है, लेकिन सार एक ही है: टीम को परिवर्तनों के बारे में सूचित करना और अनुमोदन प्राप्त करना।

एक अच्छा PR छोटा (300 लाइन कोड तक), एक कार्य पर केंद्रित होना चाहिए और इसमें क्या किया गया और क्यों किया गया इसका विवरण होना चाहिए। Google अध्ययन (2025) के अनुसार, 400 लाइन से अधिक के PR की समीक्षा में दोगुना समय लगता है, और बग का पता लगाने की संभावना 30% कम हो जाती है। कोड समीक्षा (Code Review) मर्ज से पहले किसी अन्य डेवलपर द्वारा कोड की जांच है।

IT Sectr में, हम प्रत्येक PR के लिए अनिवार्य कोड समीक्षा का अभ्यास करते हैं। यह न केवल कोड गुणवत्ता में सुधार करता है बल्कि टीम के भीतर ज्ञान फैलाने में भी मदद करता है। कोड समीक्षा जांचती है: क्या कोड आर्किटेक्चर सिद्धांतों का पालन करता है, क्या बग हैं, क्या पर्याप्त परीक्षण हैं, क्या चर सही ढंग से नामित हैं। सभी टिप्पणियों पर मर्ज होने तक PR में चर्चा की जाती है।

प्लेटफ़ॉर्म: GitHub, GitLab, Bitbucket

Git एक प्रोटोकॉल है, लेकिन सहयोग के लिए एक संस्करण नियंत्रण प्लेटफ़ॉर्म की आवश्यकता होती है जो वेब इंटरफ़ेस, पहुँच प्रबंधन, CI/CD और समीक्षा उपकरण प्रदान करता है। बाजार में तीन प्लेटफ़ॉर्म प्रमुख हैं: GitHub, GitLab और Bitbucket।

GitHub 56 मिलियन से अधिक डेवलपर्स के साथ सबसे बड़ा प्लेटफ़ॉर्म है। Microsoft के स्वामित्व में, यह Actions (CI/CD), Pages (होस्टिंग), Discussions और Copilot प्रदान करता है। मुफ्त योजना में 3 लोगों तक की टीमों के लिए असीमित निजी रिपॉजिटरी शामिल हैं। GitHub ओपन-सोर्स समुदाय में लोकप्रिय है।

GitLab एक पूर्ण DevOps प्लेटफ़ॉर्म है जिसमें एकीकृत CI/CD, कंटेनर रजिस्ट्री और बुनियादी ढाँचा प्रबंधन है। GitHub के विपरीत, GitLab को आपके अपने सर्वर (Self-Managed) पर स्थापित किया जा सकता है। Atlassian का Bitbucket Jira और Confluence के साथ कसकर एकीकृत है, जो इसे पहले से Atlassian इकोसिस्टम का उपयोग करने वाली टीमों के लिए विकल्प बनाता है।