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 }}