Git में Release Branch — यह क्या है, उद्देश्य और कार्यप्रवाह

Git में Release Branch क्या है

Release Branch (रिलीज़ ब्रांच) Git Flow में एक अस्थायी ब्रांच है, जो develop से तब बनाई जाती है जब टीम तय करती है कि सुविधाओं का वर्तमान सेट रिलीज़ के लिए तैयार है। यह उतने समय तक मौजूद रहती है जितनी अंतिम रिलीज़ तैयारी में लगता है — कुछ घंटों से लेकर कुछ दिनों तक।

रिलीज़ ब्रांच का मुख्य उद्देश्य अगले संस्करणों के विकास को रोके बिना रिलीज़ के लिए सुविधाओं के एक विशिष्ट सेट को फ्रीज़ करना है। जब रिलीज़ ब्रांच डिप्लॉयमेंट के लिए तैयार की जा रही होती है, अन्य डेवलपर अगली रिलीज़ के लिए develop में फीचर ब्रांच मर्ज करना जारी रख सकते हैं।

रिलीज़ ब्रांच में कोई नई सुविधाएँ नहीं बनाई जाती हैं — केवल बग फिक्स, एप्लिकेशन वर्जन अपडेट, लोकलाइज़ेशन और दस्तावेज़ीकरण। सभी कार्य पूरे होने के बाद, रिलीज़ ब्रांच को main (रिलीज़ के रूप में चिह्नित) और वापस develop (ताकि बगफिक्स भविष्य के संस्करणों में पहुँचें) में मर्ज किया जाता है।

Atlassian, 2024 के अनुसार, नियमित रिलीज़ चक्र वाली परियोजनाओं के लिए रिलीज़ ब्रांच अत्यंत महत्वपूर्ण हैं — वे रिलीज़ प्रक्रिया की पूर्वानुमेयता और स्थिरता सुनिश्चित करते हैं।

रिलीज़ ब्रांच का जीवनचक्र

रिलीज़ ब्रांच का जीवनचक्र निर्माण से लेकर हटाने तक कई चरणों को शामिल करता है। प्रत्येक चरण को समझने से टीम को क्रियाओं को समन्वयित करने और गलतियों से बचने में मदद मिलती है।

1. निर्माण — develop के अंतिम commit से release/2.5.0 नाम की ब्रांच बनाई जाती है। develop अगले संस्करण के लिए फीचर ब्रांच स्वीकार करना जारी रखता है।
2. तैयारी — रिलीज़ ब्रांच में build.gradle, Info.plist और अन्य कॉन्फ़िगरेशन फ़ाइलों में एप्लिकेशन वर्जन अपडेट किया जाता है।
3. बगफिक्सिंग — अंतिम परीक्षण के दौरान पाए गए गंभीर बग ठीक किए जाते हैं। केवल बग — कोई नई सुविधाएँ नहीं।
4. अंतिम परीक्षण — QA टीम रिलीज़ ब्रांच पर रिग्रेशन परीक्षण करती है। नए बग उसी ब्रांच में सुधार के लिए भेजे जाते हैं।
5. main में मर्ज — रिलीज़ ब्रांच को --no-ff फ्लैग के साथ main में मर्ज किया जाता है। रिलीज़ टैग बनाया जाता है: v2.5.0।
6. develop में मर्ज — रिलीज़ ब्रांच को वापस develop में मर्ज किया जाता है ताकि रिलीज़ के बगफिक्स वर्तमान विकास में पहुँचें।
7. हटाना — रिलीज़ ब्रांच को स्थानीय और दूरस्थ रूप से हटा दिया जाता है, क्योंकि इसका कार्य पूरा हो गया है।

चरण 6 — develop में वापस मर्ज — अक्सर भुला दिया जाता है, लेकिन यह अत्यंत महत्वपूर्ण है। इसके बिना, रिलीज़ में किए गए बगफिक्स develop तक नहीं पहुँचेंगे, और अगली रिलीज़ में वही त्रुटियाँ फिर से प्रकट हो सकती हैं।

रिलीज़ ब्रांच चरणों की सामान्य अवधि

रिलीज़ ब्रांच का जीवनकाल रिलीज़ की जटिलता और develop में कोड की गुणवत्ता पर निर्भर करता है। औसतन, एक मध्यम आकार के मोबाइल एप्लिकेशन के लिए तैयारी में 2 से 5 कार्य दिवस लगते हैं।

रिलीज़ ब्रांच में क्या किया जाता है

रिलीज़ ब्रांच में सख्ती से सीमित कार्यों का सेट किया जाता है। इस सूची से किसी भी विचलन से Git Flow मॉडल का उल्लंघन होता है और रिलीज़ स्थिरता के लिए जोखिम पैदा होता है।

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

मोबाइल प्रोजेक्ट में वर्जन अपडेट करना

रिलीज़ ब्रांच में एप्लिकेशन वर्जन नंबर अनिवार्य रूप से अपडेट किया जाता है। Android के लिए, ये build.gradle में versionCode और versionName फ़ील्ड हैं; iOS के लिए — Info.plist में CFBundleShortVersionString।

// build.gradle (ऐप-लेवल) — रिलीज़ ब्रांच में वर्जन अपडेट
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOS के लिए — Info.plist अपडेट
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Release और hotfix में अंतर

शुरुआती डेवलपर अक्सर release और hotfix ब्रांच को भ्रमित करते हैं, हालाँकि उनका उद्देश्य मौलिक रूप से अलग है। गलत ब्रांच प्रकार चुनने से महत्वपूर्ण सुधार में देरी हो सकती है या रिलीज़ प्रक्रिया बाधित हो सकती है।

• स्रोत — release develop से बनाई जाती है, hotfix main से। यह मुख्य अंतर है जो बाकी सब कुछ निर्धारित करता है।
• तात्कालिकता — release योजनाबद्ध है: टीम तय करती है कि तैयारी कब शुरू करनी है। Hotfix आपातकालीन है: प्रोडक्शन में समस्या के लिए तत्काल सुधार आवश्यक है।
• सामग्री — release में कई सुधार और वर्जन अपडेट शामिल हो सकते हैं। Hotfix में केवल एक गंभीर सुधार होता है।
• मर्ज — release main और develop में मर्ज होती है। Hotfix भी main और develop में मर्ज होती है, लेकिन प्राथमिकता के साथ।
• जीवनकाल — release 1 से 7 दिनों तक जीवित रहती है। Hotfix 30 मिनट से 1 दिन तक जीवित रहती है।

यदि रिलीज़ तैयारी के दौरान (रिलीज़ ब्रांच में) बग पाया जाता है — यह सामान्य बगफिक्स है। यदि बग प्रोडक्शन में (main पर) पाया जाता है — यह hotfix है, और यह main से बनाई जाती है, भले ही रिलीज़ ब्रांच पहले से मौजूद हो।

रिलीज़ ब्रांच नामकरण के नियम

रिलीज़ ब्रांच नामकरण का एकीकृत मानक रिपॉज़िटरी नेविगेशन को सरल बनाता है और CI/CD सिस्टम को स्वचालित रूप से यह पहचानने देता है कि ब्रांच रिलीज़ प्रक्रिया से संबंधित है।

• release/X.Y.Z — मानक Git Flow प्रारूप, जहाँ X.Y.Z रिलीज़ वर्जन है। उदाहरण: release/2.5.0।
• release/नाम — रिलीज़ कोडनेम के साथ वैकल्पिक प्रारूप। उदाहरण: release/merlin।
• release/तारीख — रिलीज़ तिथि के साथ प्रारूप। शायद ही कभी उपयोग किया जाता है, क्योंकि वर्जन तिथि से अधिक महत्वपूर्ण है। उदाहरण: release/2024-12-01।

release/X.Y.Z प्रारूप प्राथमिकता है, क्योंकि यह ब्रांच को सीधे वर्जन नंबर से जोड़ता है जो रिलीज़ को दिया जाएगा। इससे CI/CD स्क्रिप्ट द्वारा खोज और स्वचालित प्रसंस्करण सरल हो जाता है।

develop में वापस मर्ज करने की रणनीति

रिलीज़ ब्रांच का develop में वापस मर्ज (merge back) सबसे महत्वपूर्ण और साथ ही सबसे अधिक बार छोड़े जाने वाले ऑपरेशनों में से एक है। इसके बिना, रिलीज़ में किए गए सभी बगफिक्स केवल रिलीज़ वर्जन में रह जाते हैं और अगले रिलीज़ चक्र में नहीं पहुँचते।

वापस मर्ज प्रक्रिया रिलीज़ ब्रांच के main में मर्ज होने के बाद की जाती है। पहले release को develop में मर्ज किया जाता है, फिर हटा दिया जाता है। यह सुनिश्चित करता है कि develop में रिलीज़ तैयारी के दौरान किए गए सभी सुधार शामिल हों।

वापस मर्ज के बाद विरोध संभव हैं — खासकर यदि develop में पहले से नई फीचर ब्रांच दिखाई दे चुकी हैं जिन्होंने उन्हीं फ़ाइलों को बदला था। रिलीज़ के लिए जिम्मेदार डेवलपर इन विरोधों को हल करता है और develop को सर्वर पर push करता है।

कुछ टीमें इतिहास को रैखिक रखने के लिए वापस मर्ज के लिए merge के बजाय rebase का उपयोग करती हैं। हालाँकि, merge develop के लिए अधिक सुरक्षित है, क्योंकि यह commit इतिहास को फिर से नहीं लिखता जो पहले से अन्य डेवलपर्स द्वारा उपयोग किया जा रहा हो।

रिलीज़ के साथ काम करने के कमांड उदाहरण

आइए मोबाइल एप्लिकेशन वर्जन 2.5.0 की सफल रिलीज़ के बाद रिलीज़ ब्रांच के साथ काम करने का पूरा चक्र देखें: निर्माण से लेकर हटाने तक।

# 1. develop से रिलीज़ ब्रांच बनाएँ
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. वर्जन और बगफिक्स अपडेट करें
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. बग ठीक करें (केवल bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. रिलीज़ ब्रांच को सर्वर पर भेजें
git push origin release/2.5.0

# 5. release को main में मर्ज करें
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. develop में वापस मर्ज करें
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. रिलीज़ ब्रांच हटाएँ
git branch -d release/2.5.0
git push origin --delete release/2.5.0

कमांड 5 और 6 — डबल मर्ज — अत्यंत महत्वपूर्ण हैं। पहले main को रिलीज़ कोड और टैग मिलता है, फिर develop रिलीज़ के बगफिक्स के साथ सिंक्रोनाइज़ होता है। यदि चरण 6 छोड़ दिया जाता है, तो रिलीज़ के सुधार अगले विकास चक्र में नहीं पहुँचेंगे।

रिलीज़ प्रक्रिया को स्वचालित करना

नियमित रिलीज़ वाले मोबाइल प्रोजेक्ट्स के लिए, रिलीज़ ब्रांच बनाने और वर्जन अपडेट करने की प्रक्रिया को CI/CD स्क्रिप्ट के माध्यम से स्वचालित किया जा सकता है। GitHub Actions एक वर्कफ़्लो बनाने की अनुमति देता है जो बटन दबाने पर स्वचालित वर्जन अपडेट के साथ रिलीज़ ब्रांच बनाता है।

नियमित रिलीज़ वाले मोबाइल प्रोजेक्ट्स के लिए, रिलीज़ ब्रांच बनाने और वर्जन अपडेट करने की प्रक्रिया को CI/CD स्क्रिप्ट के माध्यम से स्वचालित किया जा सकता है। GitHub Actions एक वर्कफ़्लो बनाने की अनुमति देता है जो बटन दबाने पर स्वचालित वर्जन अपडेट के साथ रिलीज़ ब्रांच बनाता है।

# GitHub Actions — रिलीज़ ब्रांच निर्माण का स्वचालन
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}