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

# feature-برانچ بنانا
git flow feature start "add-auth"

# feature-برانچ مکمل کرنا (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 میں ہر کمٹ کو پروڈکٹ کے ایک مخصوص ورژن سے مطابقت رکھنی چاہیے، جسے سیمنٹک ورژننگ فارمیٹ میں ٹیگ (tag) سے نشان زد کیا گیا ہو، مثال کے طور پر v1.0.0، v1.1.0۔ main میں کوئی براہ راست ترقی نہیں کی جاتی — تبدیلیاں صرف release یا hotfix برانچوں کے ذریعے یہاں آتی ہیں۔

semver.org، 2024 کے مطابق، main میں ٹیگ MAJOR.MINOR.PATCH فارمیٹ استعمال کرتے ہیں۔ MAJOR میں API میں غیر مطابقت پذیر تبدیلیوں پر اضافہ ہوتا ہے، MINOR — پسماندہ مطابقت کے ساتھ فعالیت کے اضافے پر، PATCH — بگز کی اصلاح پر۔ Git Flow میں ہر finish release خود بخود ورژن ٹیگ کے ساتھ main میں ایک کمٹ بناتا ہے۔

Main برانچ — واحد برانچ ہے جو پروڈکشن میں تعینات کی جاتی ہے۔ موبائل پروجیکٹس کے لیے اس کا مطلب ہے کہ main میں push کرنے پر App Bundle یا IPA کی تعمیر اور Google Play / App Store میں اشاعت کا پائپ لائن شروع ہوتا ہے۔ GitLab CI/CD کی ترتیبات میں main کو force-push اور حذف کرنے سے محفوظ کیا گیا ہے۔

سیمنٹک ورژننگ اور ٹیگ

main میں ہر کمٹ کے ساتھ SemVer فارمیٹ میں ایک ٹیگ ہوتا ہے: vMAJOR.MINOR.PATCH۔ MAJOR — API میں غیر مطابقت پذیر تبدیلیوں کے لیے، MINOR — پسماندہ مطابقت کے ساتھ نئی فعالیت کے لیے، PATCH — بگز کی اصلاح کے لیے۔ مثال: v2.1.0 کا مطلب ہے نیا فیچرز کے ساتھ دوسرا میجر ریلیز اور بگ فکسز کے بغیر۔ Git Flow میں ٹیگ خود بخود finish release یا hotfix پر git flow release finish کمانڈ کے ذریعے بنائے جاتے ہیں۔

Develop برانچ: انٹیگریشن ڈویلپمنٹ لائن

Develop — Git Flow کی دوسری مستقل برانچ، جو تمام مکمل شدہ فیچرز کے انضمام کے لیے ہے۔ ڈویلپرز کوڈ ریویو اور CI/CD جانچ کے بعد feature-برانچوں کو develop میں ضم کرتے ہیں۔ Develop میں کوڈ کا تازہ ترین مستحکم ورژن ہوتا ہے جس میں موجودہ اسپرنٹ کے تمام نافذ کردہ فیچرز شامل ہوں۔

DataSift Git Flow Guide، 2024 کے مطابق، develop نامکمل انضمام کی وجہ سے عارضی طور پر غیر مستحکم ہو سکتی ہے۔ مسائل کو روکنے کے لیے ٹیمیں Continuous Integration (CI) پر عمل کرتی ہیں: develop میں ضم ہونے سے پہلے ہر فیچر ٹیسٹوں کا مکمل سیٹ پاس کرتا ہے۔ اگر CI ناکام ہو جائے — ڈویلپر اگلے انضمام سے پہلے کوڈ کو ٹھیک کرتا ہے۔ Develop ہمیشہ main کے موجودہ ورژن سے منسلک ہوتی ہے: ریلیز کے فوراً بعد develop انضمام کے ذریعے main سے مطابقت پذیر ہوتی ہے۔

Feature-برانچیں: نئی فعالیت کی ترقی

Feature-برانچیں — انفرادی فیچرز، بگ فکسز یا تجربات کی ترقی کے لیے عارضی برانچیں۔ ہر feature-برانچ develop سے بنائی جاتی ہے اور مکمل ہونے کے بعد develop میں واپس ضم ہو جاتی ہے۔ feature-برانچ کا نام عام طور پر ٹاسک نمبر یا مختصر وضاحت پر مشتمل ہوتا ہے: feature/APP-123-add-oauth، feature/redesign-profile۔ Git Flow میں feature-برانچیں لامحدود وقت تک موجود رہ سکتی ہیں۔

Pro Git Book، 2024 کے مطابق، feature-برانچیں ایک الگ تھلگ ترقی کا ماحول ہیں: ایک برانچ میں تبدیلیاں انضمام کے لمحے تک دوسری برانچوں کو متاثر نہیں کرتیں۔ موبائل پروجیکٹس میں feature-برانچیں rebase یا merge کے ذریعے develop سے مطابقت پذیر ہوتی ہیں تاکہ finish پر بڑے تنازعات سے بچا جا سکے۔ MR بنانے سے پہلے feature-برانچ کا develop پر rebase کرنے کی سفارش کی جاتی ہے۔

# دستی طور پر feature-برانچ بنانا (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-برانچ ایک اہم مسئلہ حل کرتی ہے: متوازی ترقی سے حتمی ترامیم کو الگ کرنا۔ جب release تیاری کے مرحلے میں ہوتی ہے، develop میں اگلے ریلیز کے لیے نئے فیچرز ضم ہوتے رہتے ہیں۔ مکمل ہونے کے بعد release-برانچ main میں (ٹیگ کے ساتھ) اور develop میں (ورژن بڑھانے کو مطابقت پذیر کرنے کے لیے) ضم ہو جاتی ہے۔

Hotfix-برانچیں: پروڈکشن میں فوری اصلاحات

Hotfix-برانچیں — پروڈکشن میں اہم بگز کی فوری اصلاح کے لیے عارضی برانچیں۔ Git Flow میں برانچ کی واحد قسم ہے جو main سے بنائی جاتی ہے، develop سے نہیں۔ نام کا فارمیٹ: hotfix/X.Y.Z+1 (مثال کے طور پر، hotfix/2.1.1)۔ مکمل ہونے کے بعد hotfix-برانچ بیک وقت main میں (نئے پیچ ریلیز کے طور پر) اور develop میں (تاکہ فکس اگلی ریلیز میں ضائع نہ ہو) ضم ہو جاتی ہے۔

DataSift Git Flow Guide، 2024 کے مطابق، hotfix-برانچیں زیادہ سے زیادہ مختصر ہونی چاہئیں — صرف اصلاح اور جانچ۔ Hotfix میں نئے فیچرز یا ری فیکٹرنگ شامل نہیں ہونی چاہیے۔ موبائل ڈویلپمنٹ میں hotfix کا استعمال اہم کریشز (کراش ریٹ > 0.1%)، سیکیورٹی کے خطرات یا App Store میں بلاک کرنے والے بگز کی اصلاح کے لیے کیا جاتا ہے۔

موبائل ڈویلپمنٹ کے لیے Git Flow کے فوائد اور نقصانات

Git Flow ایک واضح ڈھانچہ فراہم کرتا ہے، جو خاص طور پر بڑی ٹیموں اور باقاعدہ ریلیز والے پروجیکٹس کے لیے مفید ہے۔ فوائد: feature-برانچوں میں نامکمل فیچرز کی تنہائی، ترقی کو روکے بغیر ریلیز کی تیاری کا امکان، hotfix کے ذریعے متعدد ورژنز کی سپورٹ۔ نقصانات: ابتدائیوں کے لیے پیچیدگی، feature-برانچوں کے باقاعدہ rebase کی ضرورت، طویل المدت برانچوں پر تنازعات۔

Martin Fowler، 2024 کے مطابق، Git Flow کا سب سے بڑا نقصان طویل المدت feature-برانچیں ہیں۔ اگر کوئی فیچر 2+ ہفتے develop سے مطابقت پذیری کے بغیر تیار کیا جائے، تو انضمام پر تنازعہ نمایاں ہو جاتا ہے۔ موبائل پروجیکٹس کے لیے feature-برانچ کو روزانہ develop پر rebase کے ذریعے مطابقت پذیر کرنے کی سفارش کی جاتی ہے۔

Git Flow Continuous Deployment والے پروجیکٹس (ہر کمٹ main میں → پروڈکشن میں) کے لیے تجویز نہیں کیا جاتا۔ ایسے پروجیکٹس کے لیے GitHub Flow یا Trunk-Based Development ایک آسان اور تیز ماڈل فراہم کرتے ہیں۔ لیکن ریلیز سائیکل اور پرانے ورژنز کی سپورٹ والے پروجیکٹس کے لیے Git Flow بہترین انتخاب ہے۔

جب Git Flow ٹیم کے لیے نقصان دہ ہے

Git Flow تین صورتوں میں مسئلہ بن جاتا ہے: ٹیم 5 افراد سے کم ہو (ضرورت سے زیادہ پیچیدگی)، Continuous Deployment ہو (ترسیل میں تاخیر)، rebase کا نظم و ضبط نہ ہو (طویل المدت feature-برانچیں merge تنازعات پیدا کرتی ہیں)۔ اگر ٹیم برانچوں کے انضمام اور تنازعات کے حل پر 20% سے زیادہ وقت صرف کرتی ہے — تو Git Flow اس ٹیم کے لیے موزوں نہیں ہے چاہے وہ بڑی ہی کیوں نہ ہو۔

Git Flow کے متبادل: GitHub Flow اور Trunk-Based Development

Git Flow کے متبادل CI/CD پر عمل کرنے والی ٹیموں کے لیے ایک آسان عمل پیش کرتے ہیں۔ GitHub Flow صرف ایک مستقل برانچ (main) اور feature-برانچیں استعمال کرتا ہے۔ ہر فیچر main سے بنایا جاتا ہے، ریویو اور CI کے بعد main میں واپس ضم ہو جاتا ہے اور فوری طور پر تعینات ہو جاتا ہے۔ GitHub Flow آسان ہے، لیکن نامکمل فیچرز کی تنہائی اور متوازی ریلیز کی تیاری کو سپورٹ نہیں کرتا۔

GitHub Docs، 2024 کے مطابق، Trunk-Based Development (TBD) اس سے بھی آگے جاتا ہے: تمام ڈویلپر ایک برانچ (trunk) میں کام کرتے ہیں، 1–2 دن کی قلیل المدت feature-برانچیں استعمال کرتے ہیں۔ Feature toggles (فیچر فلیگ) نامکمل کوڈ کی نمائش کو کنٹرول کرتے ہیں۔ TBD میں CI/CD اور جانچ آٹومیشن کا اعلیٰ نظم و ضبط درکار ہے۔

• GitHub Flow — ایک main + feature-برانچیں، CI/CD اور چھوٹی ٹیموں کے لیے مثالی
• GitLab Flow — environment-برانچوں (staging، production) کے ساتھ Git Flow کو ترقی دیتا ہے
• Trunk-Based Development — ایک برانچ + feature toggles، زیادہ سے زیادہ CI/CD، کم سے کم انضمام
• One Flow — develop برانچ کے بغیر آسان Git Flow، صرف main + feature + release