Git Flow: यह क्या है, ब्रैन्चिंग मॉडल और परियोजनाओं में उपयोग

Git Flow क्या है?

Git Flow एक Git ब्रैन्चिंग मॉडल है जो विकास, रिलीज और सुधारों के प्रबंधन के लिए शाखाओं और विलय नियमों की एक सर्वंश संरचना परिभाषित करता है। Vincent Driessen ने जनवरी 2010 में “A successful Git branching model” लेख प्रकाशित किया, और तब से Git Flow कॉर्पोरेट Java और .NET डेवलपमेंट में डी फैक्टो मानक बन गया है। मुख्य विचार कोड को अलग-अलग स्थिरता स्तरों के साथ पांच प्रकार की शाखाओं में विभाजित करना है।

Atlassian Git Tutorials, 2024 के अनुसार, Git Flow दो स्थायी शाखाओं पर आधारित है: main (पहले master) और develop। अन्य सभी शाखाएँ अस्थायी हैं: feature, release, hotfix। प्रत्येक शाखा प्रकार का एक निश्चित जीवनचक्र और विलय नियम होते हैं। मोबाइल डेवलपमेंट में, Git Flow का उपयोग नियमित रिलीज चक्रों (2–4 सप्ताह) और एकाधिक संस्करणों के समर्थन वाले परियोजनाओं में किया जाता है।

Git Flow सरल मॉडल (GitHub Flow) से अलग है क्योंकि इसे एकीकरण के लिए एक अलग develop शाखा की आवश्यकता होती है। यह विलय प्रक्रिया में एक कदम जोड़ता है, लेकिन अधूरी सुविधाओं को रिलीज-तैयार कोड से अतिरिक्त पृथक्करण प्रदान करता है।

Vincent Driessen और Git Flow का इतिहास

2010 में, Vincent Driessen ने “A successful Git branching model” पोस्ट प्रकाशित किया, जो Git इतिहास में सबसे अधिक उद्धृत में से एक बन गया। मॉडल निश्चित रिलीज और समानांतर संस्करण समर्थन वाले एक परियोजना के लिए बनाया गया था। 2020 में, Driessen ने स्वीकार किया कि Git Flow आधुनिक CI/CD प्रथाओं के लिए पुराना हो चुका है, लेकिन मॉडल लंबे रिलीज चक्र और पुराने संस्करणों को समर्थन करने की आवश्यकता वाले परियोजनाओं के लिए प्रासंगिक बना हुआ है।

# Git Flow आरंभ करें
git flow init

# फिचर शाखा बनाएँ
git flow feature start "add-auth"

# फिचर शाबा समाप्त करें (develop में विलय करें)
git flow feature finish "add-auth"

# release बनाएँ
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main शाखा: रिलीज कोड और टैगिंग

Main (पहले master) प्राथमिक शाखा है जिसमें केवल तैनात के लिए तैयार रिलीज कोड होता है। main में प्रत्येक कमिट एक विशिष्ट उत्पाद संस्करण के अनुरूप होना चाहिए, जो अर्थपूर्ण संस्करण प्रारूप में टैग किया गया हो, जैसे v1.0.0, v1.1.0। main में कोई सीधा विकास नहीं होता — परिवर्तन केवल release या hotfix शाखाओं के माध्यम से यहाँ पहुंचते हैं।

semver.org, 2024 के अनुसार, main में टैग MAJOR.MINOR.PATCH प्रारूप का उपयोग करते हैं। MAJOR असंगत API परिवर्तनों के लिए बढ़ाया जाता है, MINOR पीछे की अनुकूलता के साथ कार्यक्षमता जोड़ने के लिए, PATCH बग फिक्स के लिए। Git Flow में, प्रत्येक फिनिश release संस्करण टैग के साथ main में स्वचालित रूप से एक कमिट बनाता है।

Main शाखा एकमात्र है जो उत्पादन में तैनात होती है। मोबाइल परियोजनाओं के लिए, इसका मतलब है कि main में पुश करने से App Bundle या IPA बिल्ड पाइपलाइन और Google Play / App Store में प्रकाशन शुरू हो जाता है। GitLab CI/CD सेटिंग्स में, main फॉर्स-पुश और हटाने से सुरक्षित है।

अर्थपूर्ण संस्करण और टैग

main में प्रत्येक कमिट के साथ एक टैग होता है SemVer प्रारूप में: vMAJOR.MINOR.PATCH। MAJOR — असंगत API परिवर्तनों के लिए, MINOR — पीछे की अनुकूलता के साथ नई कार्यक्षमता के लिए, PATCH — बग फिक्स के लिए। उदाहरण: v2.1.0 का मतलब बिना बगफिक्स के नई सुविधाओं के साथ दूसरा प्रमुख रिलीज। Git Flow में, टैग git flow release finish कमांड के माध्यम से release या hotfix खत्म करने पर स्वचालित रूप से बनाए जाते हैं।

Develop शाखा: विकास की एकीकरण रेखा

Develop Git Flow में दूसरी स्थायी शाखा है, जो सभी पूर्ण सुविधाओं के एकीकरण के लिए डिजाइन की गई है। डेवलपर कोड समीक्षा और CI/CD जाँच पार करने के बाद फिचर शाखाओं को develop में विलय करते हैं। Develop में कोड का नवीनतम स्थिर संस्करण होता है, जिसमें वर्तमान स्प्रिंट की सभी लागू सुविधाएँ शामिल होती हैं।

DataSift Git Flow Guide, 2024 के अनुसार, develop चलरहे एकीकरणों के कारण अस्थायी रूप से अस्थिर हो सकता है। समस्याओं को रोकने के लिए, टीमें सतत एकीकरण (CI) का अभ्यास करती हैं: प्रत्येक सुविधा को develop में विलय से पहले पूर्ण परीक्षण सूट पार करनी होती है। यदि CI विफल होता है, तो डेवलपर अगले विलय से पहले कोड ठीक करता है। Develop हमेशा main के वर्तमान संस्करण से जुड़ी होती है: रिलीज के तुरंत बाद, develop को विलय के माध्यम से main के साथ सिंक किया जाता है।

Feature शाखाएँ: नई कार्यक्षमता विकसित करना

Feature शाखाएँ अलग-अलग सुविधाओं, बगफिक्स या प्रयोगों के विकास के लिए अस्थायी शाखाएँ हैं। प्रत्येक फिचर शाखा develop से बनाई जाती है और पूर्ण होने पर develop में वापस विलय हो जाती है। फिचर शाखा का नाम आमतौर पर कार्य संख्या या संक्षिप्त विवरण रखता है: feature/APP-123-add-oauth, feature/redesign-profile। Git Flow में, फिचर शाखाएँ अनिश्चित समय तक मौजूद रह सकती हैं।

Pro Git Book, 2024 के अनुसार, फिचर शाखाएँ एक पृथक्कृत विकास वातावरण हैं: एक शाखा में परिवर्तन विलय होने तक दूसरों को प्रभावित नहीं करते हैं। मोबाइल परियोजनाओं में, फिचर शाखाओं को खत्म करते समय बड़े टकरावों से बचने के लिए rebase या merge के माध्यम से develop के साथ सिंक किया जाता है। MR बनाने से पहले फिचर शाखा को develop पर rebase करने की अनुशंसा दी जाती है।

# मैनुअल फिचर शाखा निर्माण (git flow के बिना)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# CLI के माध्यम से GitLab में MR बनाएँ
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release शाखाएँ: रिलीज तैयार करना

Release शाखाएँ रिलीज तैयार करने के लिए develop से बनाई गई अस्थायी शाखाएँ हैं। जब develop में एक नए संस्करण के लिए पर्याप्त सुविधाएँ होती हैं, तो टीम release/X.Y.Z शाखा बनाती है (उदाहरण: release/2.1.0)। इस शाखा में केवल अंतिम परिवर्तन किए जाते हैं: संस्करण वृद्धि, स्थानीयकरण अद्यतन, अंतिम परीक्षण, गंभीर बग फिक्स।

Atlassian Git Tutorials, 2024 के अनुसार, release शाखा एक मुख्य समस्या का समाधान करती है: अंतिम परिवर्तनों को समानांतर विकास से अलग करना। जब रिलीज तैयार हो रहा होता है, अगले रिलीज के लिए नई सुविधाएँ develop में विलय होती रहती हैं। पूर्ण होने पर, release शाखा को main (टैग के साथ) और develop (संस्करण वृद्धि को सिंक करने के लिए) में विलय किया जाता है।

Hotfix शाखाएँ: उत्पादन में अत्यन्त सुधार

Hotfix शाखाएँ उत्पादन में गंभीर बगों को तुरंत ठीक करने के लिए अस्थायी शाखाएँ हैं। Git Flow में एकमात्र शाखा प्रकार जो develop के बजाय main से बनाया जाता है। नाम प्रारूप: hotfix/X.Y.Z+1 (उदाहरण: hotfix/2.1.1)। पूर्ण होने पर, hotfix शाखा एकसाथ main (एक नए पैच रिलीज के रूप में) और develop (ताकि फिक्स भविष्य के रिलीज में खो न जाए) में विलय हो जाती है।

DataSift Git Flow Guide, 2024 के अनुसार, hotfix शाखाएँ यथासंभव छोटी होनी चाहिए — केवल फिक्स और परीक्षण। hotfix में नई सुविधाएँ या रिफैक्टरिंग शामिल नहीं होनी चाहिए। मोबाइल डेवलपमेंट में, hotfix का उपयोग गंभीर क्रैश (crash rate > 0.1%), सुरक्षा कमजरियों या App Store में अवरोधक बगों के लिए किया जाता है।

मोबाइल डेवलपमेंट के लिए Git Flow के लाभ और हानियाँ

Git Flow एक स्पष्ट संरचना प्रदान करता है जो विशेष रूप से बड़ी टीमों और नियमित रिलीज वाले परियोजनाओं के लिए उपयोगी है। लाभ: फिचर शाखाओं में अधूरी सुविधाओं का पृथक्करण, विकास को अवरुद्ध किए बिना रिलीज तैयार करने की क्षमता, hotfix के माध्यम से एकाधिक संस्करणों का समर्थन। हानियाँ: शुरुआतीयों के लिए जटिलता, नियमित फिचर शाखा rebase की आवश्यकता, लंबे समय तक चलने वाली शाखाओं में टकराव।

Martin Fowler, 2024 के अनुसार, Git Flow का मुख्य नुकसान लंबे समय तक चलने वाली फिचर शाखाएँ हैं। यदि कोई सुविधा develop के साथ सिंक किए 2+ सप्ताह विकसित होती है, तो विलय का टकराव महत्वपूर्ण हो जाता है। मोबाइल परियोजनाओं के लिए, रोजाना rebase के माध्यम से फिचर शाखा को develop पर सिंक करने की अनुशंसा दी जाती है।

Git Flow सतत परियोजन (प्रत्येक कमिट main में → उत्पादन) वाले परियोजनाओं के लिए अनुशंसित नहीं है। ऐसे परियोजनाओं के लिए, GitHub Flow या Trunk-Based Development एक सरल और त्वरित मॉडल प्रदान करते हैं। लेकिन रिलीज चक्रों और पुराने संस्करणों के समर्थन वाले परियोजनाओं के लिए, Git Flow अभी भी सबसे उपयुक्त विकल्प है।

कब Git Flow टीम के लिए हानिकारक है

Git Flow तीन स्थितियों में समस्या बन जाता है: 5 से कम सदस्यों वाली टीम (अनावश्यक जटिलता), सतत परियोजन (वितरण में विलंब), rebase अनुशासन की कमी (लंबे समय तक चलने वाली फिचर शाखाएँ विलय टकराव पैदा करती हैं)। यदि कोई टीम शाखाओं के विलय और टकरावों के समाधान में 20% से अधिक समय बिताती है — तो Git Flow उस टीम के लिए उपयुक्त नहीं है, चाहे टीम कितनी भी बड़ी क्यों न हो।

Git Flow के विकल्प: GitHub Flow और Trunk-Based Development

Git Flow के विकल्प CI/CD का अभ्यास करने वाली टीमों के लिए एक सरल प्रक्रिया प्रदान करते हैं। GitHub Flow केवल एक स्थायी शाखा (main) और फिचर शाखाओं का उपयोग करता है। प्रत्येक सुविधा main से बनाई जाती है, समीक्षा और CI के बाद वापस main में विलय होकर तुरंत तैनात हो जाती है। GitHub Flow सरल है लेकिन अधूरी सुविधाओं के पृथक्करण या समानांतर रिलीज तैयारी का समर्थन नहीं करता है।

GitHub Docs, 2024 के अनुसार, Trunk-Based Development (TBD) और आगे जाता है: सभी डेवलपर एक ही शाखा (trunk) में काम करते हैं, 1–2 दिन की अल्पकालीन फिचर शाखाओं का उपयोग करते हैं। Feature toggles अधूरे कोड की दृश्यता को नियंत्रित करते हैं। TBD के लिए उच्च CI/CD अनुशासन और परीक्षण स्वचालन की आवश्यकता होती है।

• GitHub Flow — एक main + फिचर शाखाएँ, CI/CD और छोटी टीमों के लिए आदर्श
• GitLab Flow — Git Flow को परिवेश शाखाओं (staging, production) के साथ विस्तारित करता है
• Trunk-Based Development — एक शाखा + feature toggles, अधिकतम CI/CD, न्यूनतम विलय
• One Flow — develop शाखा के बिना सरलीकृत Git Flow, केवल main + feature + release