Git में Main और Master Branch: यह क्या है और मुख्य शाखा की आवश्यकता क्यों है

Git में Main / Master Branch क्या है

Main Branch (या Master — रिपॉजिटरी सेटिंग्स पर निर्भर करता है) डिफ़ॉल्ट शाखा है जो किसी भी Git रिपॉजिटरी को इनिशियलाइज़ करने पर बनाई जाती है। यह प्रोजेक्ट की मुख्य शाखा है और इसमें प्रोडक्शन में डिप्लॉय करने के लिए तैयार कोड होता है।

develop के विपरीत, जहाँ नई सुविधाओं के साथ दैनिक कार्य जारी रहता है, main प्रोजेक्ट का शोकेस है। main में कोड का प्रत्येक वर्जन पूरे चक्र से गुज़रा है: feature शाखा में डेवलपमेंट, develop में एकीकरण, release शाखा में रिलीज़ तैयारी और अंतिम परीक्षण। उसके बाद ही परिवर्तन main तक पहुँचते हैं।

मुख्य सिद्धांत: main हमेशा स्थिर होना चाहिए। यदि main में कोई त्रुटि पाई जाती है, तो इसका मतलब है कि तत्काल hotfix जारी करने की आवश्यकता है। इसलिए, पेशेवर प्रोजेक्ट्स में, main को शाखा सुरक्षा नियमों द्वारा आकस्मिक परिवर्तनों से सुरक्षित किया जाता है।

Git Book के अनुसार, main अद्वितीय गुणों वाली कोई विशेष शाखा नहीं है, बल्कि एक कमिट का सामान्य संदर्भ है जिसे परंपरा के अनुसार मुख्य माना जाता है। Git सिस्टम स्तर पर main और किसी अन्य शाखा के बीच कोई अंतर नहीं करता है।

master से main में संक्रमण

ऐतिहासिक रूप से, Git में डिफ़ॉल्ट शाखा को master कहा जाता था। जून 2020 में, Black Lives Matter आंदोलन ने IT उद्योग में master और slave शब्दों की ओर ध्यान आकर्षित किया। GitHub ने डिफ़ॉल्ट शाखा के लिए main शब्द में संक्रमण की घोषणा की।

अक्टूबर 2020 से, GitHub पर सभी नई रिपॉजिटरी main शाखा के साथ बनाई जाती हैं। GitLab और Bitbucket ने भी डिफ़ॉल्ट नाम के रूप में main के लिए समर्थन लागू किया। Git 2.28 (जुलाई 2020) ने डिफ़ॉल्ट शाखा नाम कॉन्फ़िगर करने के लिए init.defaultBranch विकल्प जोड़ा।

तकनीकी रूप से, मौजूदा शाखा का नाम master से main में बदलना एक सरल ऑपरेशन है। मुख्य चुनौती CI/CD कॉन्फ़िगरेशन, दस्तावेज़ीकरण और डेवलपर्स की स्थानीय रिपॉजिटरी में सभी संदर्भों को अपडेट करना है।

मौजूदा रिपॉजिटरी में शाखा का नाम बदलने के लिए, चलाएँ:

# master का स्थानीय रूप से main में नाम बदलना
git branch -m master main

# रिमोट रिपॉजिटरी अपडेट करना
git push -u origin main

# सर्वर पर पुराने master को हटाना
git push origin --delete master

# सर्वर पर HEAD अपडेट करना
# (GitHub वेब इंटरफ़ेस के माध्यम से: Settings → Branches → Default branch)

Git Flow और GitHub Flow में main की भूमिका

Git Flow और GitHub Flow main शाखा की भूमिका को अलग-अलग तरीके से परिभाषित करते हैं। मॉडल का चुनाव टीम के आकार, रिलीज़ आवृत्ति और कोड स्थिरता आवश्यकताओं पर निर्भर करता है।

मोबाइल डेवलपमेंट के लिए, Git Flow मानक है, क्योंकि App Store और Google Play में ऐप प्रकाशित करने के निश्चित रिलीज़ चक्र होते हैं। GitHub Flow उन वेब प्रोजेक्ट्स के लिए अधिक उपयुक्त है जिन्हें दिन में कई बार डिप्लॉय किया जा सकता है।

GitHub Flow — सरलीकृत दृष्टिकोण

GitHub Flow में, कोई develop शाखा नहीं है। सभी feature शाखाएँ सीधे main से बनाई जाती हैं, और पूरा होने पर Pull Request के माध्यम से वापस मर्ज की जाती हैं। main में प्रत्येक मर्ज स्वचालित रूप से प्रोडक्शन में डिप्लॉयमेंट ट्रिगर करता है। इस मॉडल के लिए उच्च स्तर के परीक्षण ऑटोमेशन और टीम अनुशासन की आवश्यकता होती है।

GitHub Flow में, कोई develop शाखा नहीं है। सभी feature शाखाएँ सीधे main से बनाई जाती हैं, और पूरा होने पर Pull Request के माध्यम से वापस मर्ज की जाती हैं। main में प्रत्येक मर्ज स्वचालित रूप से प्रोडक्शन में डिप्लॉयमेंट ट्रिगर करता है। इस मॉडल के लिए उच्च स्तर के परीक्षण ऑटोमेशन और टीम अनुशासन की आवश्यकता होती है।

main शाखा की सुरक्षा

शाखा सुरक्षा main के लिए किसी भी व्यावसायिक प्रोजेक्ट में अनिवार्य सेटिंग है। इसके बिना, एक आकस्मिक push अधूरा कोड प्रोडक्शन में भेज सकता है या सभी उपयोगकर्ताओं के लिए काम कर रहे एप्लिकेशन को तोड़ सकता है।

• Require pull request — main में सीधा push निषिद्ध है। सभी परिवर्तन समीक्षा के साथ PR के माध्यम से।
• Require approvals — main में मर्ज करने के लिए न्यूनतम 2 अनुमोदन (यदि कोई समीक्षक कुछ चूक जाए)।
• Require status checks — मर्ज करने से पहले सभी CI/CD जाँचें सफल होनी चाहिए।
• Require up-to-date — PR नवीनतम main कमिट पर आधारित होना चाहिए।
• Include administrators — सुरक्षा रिपॉजिटरी मालिकों पर भी लागू होती है।
• Require signed commits — main में सभी कमिट GPG कुंजी से हस्ताक्षरित होने चाहिए।

सभी छह नियमों को कॉन्फ़िगर करना 10,000+ उपयोगकर्ताओं वाले मोबाइल प्रोजेक्ट्स के लिए मानक है। छोटे प्रोजेक्ट्स के लिए, पहले तीन नियम पर्याप्त हैं।

विभिन्न प्रकार के प्रोजेक्ट्स के लिए सुरक्षा स्तरों की तुलना

main की सुरक्षा का स्तर प्रोजेक्ट के पैमाने पर निर्भर करता है। एक स्टार्टअप न्यूनतम सुरक्षा के साथ काम चला सकता है, जबकि एंटरप्राइज़ एप्लिकेशन को अधिकतम प्रतिबंधों की आवश्यकता होती है।

main में रिलीज़ और टैग

टैगिंग main में विशिष्ट कमिट के नामित संदर्भ बनाने की प्रथा है। प्रत्येक टैग प्रोडक्शन में जारी एप्लिकेशन के एक वर्जन से मेल खाता है। यह डिबगिंग या पैच के लिए किसी भी पिछले रिलीज़ पर तुरंत स्विच करने की अनुमति देता है।

मोबाइल डेवलपमेंट में टैग नामकरण का मानक SemVer (सिमेंटिक वर्जनिंग) है: v1.2.3, जहाँ पहला नंबर मेजर वर्जन (ब्रेकिंग चेंजेस), दूसरा माइनर वर्जन (नई सुविधाएँ), और तीसरा पैच (सुधार) है।

release शाखा को main में मर्ज करने के बाद टैग बनाया जाता है। फिर इस कमिट को CI/CD में बनाया जाता है, हस्ताक्षरित किया जाता है और ऐप स्टोर पर भेजा जाता है। यदि टैग में कोई त्रुटि पाई जाती है, तो उस टैग से hotfix शाखा बनाई जाती है।

# एनोटेटेड रिलीज़ टैग बनाना
git tag -a v2.4.1 -m "Release version 2.4.1"

# सर्वर पर टैग भेजना
git push origin v2.4.1

# रिपॉजिटरी में सभी टैग देखना
git tag -l "v2.*"

# किसी विशिष्ट टैग से hotfix शाखा बनाना
git checkout -b hotfix/crash-fix v2.4.1

Git Flow शाखा पदानुक्रम

Git Flow में शाखा पदानुक्रम को समझना सहयोगी डेवलपमेंट को ठीक से व्यवस्थित करने का आधार है। प्रत्येक शाखा प्रकार का अपना स्रोत, उद्देश्य और मर्ज नियम होते हैं।

• Main (स्तर 1) — मूल शाखा, केवल रिलीज़ वर्जन रखती है। रिपॉजिटरी इनिशियलाइज़ करने पर बनाई जाती है।
• Develop (स्तर 2) — प्रोजेक्ट शुरू होने पर main से बनाई जाती है। सभी सुविधाओं का एकीकरण कोड रखती है।
• Feature (स्तर 3) — develop से बनाई जाती है। व्यक्तिगत सुविधाओं का पृथक डेवलपमेंट।
• Release (स्तर 2) — develop से बनाई जाती है। विशिष्ट रिलीज़ को लॉन्च के लिए तैयार करना।
• Hotfix (स्तर 2) — main से बनाई जाती है। क्रिटिकल प्रोडक्शन त्रुटियों का तत्काल सुधार।

महत्वपूर्ण नियम: feature कभी सीधे main में मर्ज नहीं होती। feature → develop → release → main सही मर्ज श्रृंखला है। इस नियम का उल्लंघन पूरे Git Flow मॉडल के उद्देश्य को समाप्त कर देता है।

main के साथ काम करने के कमांड उदाहरण

एक परिदृश्य पर विचार करें: टीम ने रिलीज़ v2.5.0 की तैयारी पूरी कर ली है। release शाखा की समीक्षा हो चुकी है और वह main में मर्ज होने के लिए तैयार है। मर्ज करने के बाद, एक टैग बनाया जाता है और रिलीज़ प्रकाशित की जाती है।

# main पर स्विच करना और अपडेट करना
git checkout main
git pull origin main

# सत्यापित release शाखा को मर्ज करना
git merge --no-ff release/2.5.0

# रिलीज़ टैग बनाना
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# main और टैग को सर्वर पर भेजना
git push origin main --tags

--no-ff फ़्लैग (नो फ़ास्ट-फ़ॉरवर्ड) मर्ज कमिट बनाने की गारंटी देता है, भले ही मर्ज को केवल पॉइंटर को हिलाकर किया जा सकता हो। यह जानकारी संरक्षित करता है कि परिवर्तन release शाखा से आए हैं, जिससे इतिहास विश्लेषण आसान हो जाता है।

main के माध्यम से hotfix के साथ काम करना

यदि प्रोडक्शन में कोई क्रिटिकल त्रुटि पाई जाती है, तो प्रक्रिया सामान्य रिलीज़ से भिन्न होती है। Hotfix main से बनाया जाता है, और सुधार के बाद, इसे main और develop दोनों में मर्ज किया जाता है।

यदि प्रोडक्शन में कोई क्रिटिकल त्रुटि पाई जाती है, तो प्रक्रिया सामान्य रिलीज़ से भिन्न होती है। Hotfix main से बनाया जाता है, और सुधार के बाद, इसे main और develop दोनों में मर्ज किया जाता है।

# main से hotfix शाखा बनाना
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# सुधार और कमिट करना
git add src/fix/
git commit -m "Fix crash on login screen"

# hotfix को वापस main में मर्ज करना
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# hotfix को develop में भी मर्ज करना
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# hotfix शाखा हटाना
git branch -d hotfix/2.5.1-crash-fix