Git میں Feature Branch: یہ کیا ہے، برانچ کیسے بنائیں اور ان کے ساتھ کام کریں

Git میں Feature Branch کیا ہے

Feature Branch (فیچر برانچ) Git میں ایک عارضی برانچ ہے جو کسی خاص فعالیت کو تیار کرنے کے لیے develop سے بنائی جاتی ہے۔ طویل عرصے تک رہنے والی main اور develop برانچز کے برعکس، feature برانچز محدود وقت — کچھ گھنٹوں سے کچھ ہفتوں تک — کے لیے موجود رہتی ہیں۔

feature branch کا بنیادی مقصد ایک کام سے متعلق تبدیلیوں کو باقی کوڈ سے الگ کرنا ہے۔ ڈویلپر اپنی برانچ میں تجربہ کر سکتا ہے، متعدد commits کر سکتا ہے اور کوڈ کو توڑ بھی سکتا ہے، ٹیم کے دیگر اراکین کے کام کو متاثر کیے بغیر۔

ڈویلپمنٹ مکمل ہونے کے بعد، feature برانچ کو لازمی کوڈ جائزے کے ساتھ Pull Request کے ذریعے واپس develop میں ضم کر دیا جاتا ہے۔ انضمام کے بعد، ریپوزٹری کو صاف رکھنے کے لیے برانچ کو عام طور پر حذف کر دیا جاتا ہے۔

Vincent Driessen، 2010 کے مطابق، feature برانچز کے ساتھ Git Flow ماڈل مختلف اقسام کی برانچز کے درمیان ذمہ داریوں کی واضح تقسیم کی وجہ سے صنعت کا معیار بن گیا۔

Feature Branch کے ساتھ ورک فلو

ورک فلو feature branch کے ساتھ ان اقدامات کے سلسلے پر مشتمل ہے جو ڈویلپر ہر نئی خصوصیت کے لیے انجام دیتا ہے۔ یہ عمل انضمام کے تنازعات کو کم سے کم کرتا ہے اور کوڈ کے معیار کو یقینی بناتا ہے۔

1. برانچ بنانا develop کے تازہ ترین commit سے۔ ڈویلپر develop پر جاتا ہے، اسے اپ ڈیٹ کرتا ہے اور ایک نئی feature برانچ بناتا ہے۔
2. ڈویلپمنٹ اور commits feature برانچ میں۔ ڈویلپر تبدیلیاں کرتا ہے، واضح وضاحت کے ساتھ commits کرتا ہے اور وقتاً فوقتاً برانچ کو ریموٹ ریپوزٹری میں push کرتا ہے۔
3. develop کے ساتھ ہم آہنگی — ڈویلپمنٹ کے دوران، مرکزی برانچ آگے بڑھ سکتی ہے۔ ڈویلپر اپنی feature برانچ میں develop کا rebase یا merge کرتا ہے۔
4. Pull Request بنانا — جب فیچر تیار ہو جاتا ہے، ڈویلپر کوڈ کے جائزے کے لیے PR کھولتا ہے۔ ٹیم کوڈ کا جائزہ لیتی ہے اور تبصرے چھوڑتی ہے۔
5. انضمام اور حذف کرنا — PR کی منظوری کے بعد، برانچ develop میں ضم ہو جاتی ہے اور مقامی اور ریموٹ دونوں جگہوں سے حذف کر دی جاتی ہے۔

develop کے ساتھ وقتاً فوقتاً ہم آہنگی انتہائی اہم ہے۔ feature برانچ جتنی دیر develop سے تبدیلیوں کو ضم کیے بغیر رہتی ہے، حتمی انضمام میں تنازعات کا امکان اتنا ہی زیادہ ہوتا ہے۔

Feature برانچ کی ہم آہنگی کی تعدد

Feature برانچ کے نام رکھنے کے قواعد

برانچ کا نام رکھنا ٹیم کے نظم و ضبط کا ایک اہم حصہ ہے۔ ایک یکساں نام رکھنے کا معیار فوری طور پر یہ شناخت کرنے کی اجازت دیتا ہے کہ کس کام پر کام ہو رہا ہے اور یہ کون کر رہا ہے۔

• feature/نام — کلاسک Git Flow میں feature/ سابقہ استعمال ہوتا ہے۔ مثال: feature/added-auth-module۔
• feature/JIRA-123-وضاحت — ٹریکنگ سسٹم میں کام کے نمبر سے لنک۔ مثال: feature/PROJ-42-add-login۔
• feature/قسم/نام — کام کی قسم کے اشارے کے ساتھ توسیعی شکل۔ مثال: feature/feat/analytics-dashboard۔

JIRA، Trello یا کسی اور سسٹم سے کام کا ID استعمال کرنا بہترین عمل ہے۔ یہ خود بخود کوڈ کو کام سے جوڑتا ہے اور git log کے ذریعے برانچ تلاش کرنے کو آسان بناتا ہے۔

Pull Request کا عمل

Pull Request (یا GitLab میں Merge Request) feature برانچ کو develop میں ضم کرنے کی درخواست ہے۔ PR صرف ایک تکنیکی عمل نہیں ہے، بلکہ ایک ٹیم کوڈ جائزہ کا عمل ہے جو کوڈ کے معیار کو بہتر بناتا ہے اور ٹیم کے اندر علم پھیلاتا ہے۔

ایک اچھے PR میں کام کی مختصر وضاحت کے ساتھ عنوان، ٹکٹ کا لنک اور تبدیلیوں کی وضاحت ہوتی ہے۔ ڈویلپر کو بتانا چاہیے کہ اصل میں کیا کیا گیا، کون سی فائلیں تبدیل کی گئیں اور کیا پروجیکٹ کے دوسرے حصوں کے لیے ممکنہ خطرات ہیں۔

ٹیم PR میں کوڈ کا جائزہ لیتی ہے، تبصرے چھوڑتی ہے، تبدیلیوں کی درخواست کرتی ہے (change requests) اور انضمام کی منظوری دیتی ہے (approve)۔ منظوری کے بعد، merge یا squash merge انجام دیا جاتا ہے۔

موبائل ڈویلپمنٹ میں PR کے جائزے کا اوسط وقت 4 سے 24 گھنٹے تک ہے۔ Danger لائبریری براہ راست PR میں linters اور ٹیسٹ چلا کر کچھ جانچوں کو خودکار کرتی ہے۔

اچھا PR بنانے کی سفارشات

• سائز — 300-400 لائنوں سے زیادہ تبدیلیاں نہیں۔ بڑے PRs کا جائزہ لینا مشکل ہے، جائزے کا معیار گر جاتا ہے۔
• ایک PR — ایک کام — ایک درخواست میں غیر متعلقہ تبدیلیوں کو ملانے سے گریز کریں۔
• اسکرین شاٹس — UI تبدیلیوں کے لیے پہلے اور بعد کے اسکرین شاٹس منسلک کریں۔
• ٹیسٹ — نئی فعالیت کے لیے یونٹ ٹیسٹ لکھیں اور انہیں PR میں شامل کریں۔

Feature برانچ کو ضم کرنے کی حکمت عملی

PR کی منظوری کے بعد، feature برانچ کو مختلف طریقوں سے develop میں ضم کیا جا سکتا ہے۔ انضمام کی حکمت عملی کا انتخاب commit کی تاریخ اور تبدیلیوں کو واپس لانے کی صلاحیت کو متاثر کرتا ہے۔

• Merge commit — ایک انضمام commit بناتا ہے، feature برانچ کی پوری commit تاریخ کو محفوظ رکھتا ہے۔ تاریخ مکمل رہتی ہے، لیکن برانچنگ گراف زیادہ پیچیدہ ہو جاتا ہے۔
• Squash merge — feature برانچ کے تمام commits کو ایک میں ملا دیتا ہے اور اسے develop کے اوپر شامل کرتا ہے۔ تاریخ صاف ہو جاتی ہے، لیکن درمیانی commits کے بارے میں معلومات ضائع ہو جاتی ہیں۔
• Rebase and merge — feature برانچ کے commits کو develop کے تازہ ترین commit کے اوپر دوبارہ لکھتا ہے اور اضافی commit کے بغیر ضم کرتا ہے۔ تاریخ لکیری رہتی ہے۔

بار بار ریلیز والے موبائل پروجیکٹس کے لیے، عام طور پر squash merge استعمال کیا جاتا ہے: یہ develop میں صاف تاریخ فراہم کرتا ہے، جبکہ ڈویلپمنٹ کی تفصیلات PR کی وضاحت اور ٹریکر کام میں رہتی ہیں۔

Feature Branch کے ساتھ کام کرتے وقت عام غلطیاں

تجربہ کار ڈویلپرز بھی feature برانچز کے ساتھ کام کرتے وقت غلطیاں کرتے ہیں۔ عام مسائل کا علم وقت اور ڈیٹا کے ضیاع سے بچنے میں مدد کرتا ہے۔

• برانچ کی بہت لمبی زندگی — ایک feature برانچ develop کے ساتھ ہم آہنگی کے بغیر 2-3 ہفتوں سے زیادہ زندہ رہتی ہے، جس سے بڑے پیمانے پر انضمام کے تنازعات پیدا ہوتے ہیں۔
• غیر واضح وضاحت والے Commits — “fix” یا “update” جیسے پیغامات یہ نہیں بتاتے کہ کیا تبدیل کیا گیا اور کیوں۔
• کاموں کا ملاوٹ — ایک ہی feature برانچ میں دو غیر متعلقہ خصوصیات تیار کی جاتی ہیں، جس سے انتخابی واپسی ناممکن ہو جاتی ہے۔
• ہم آہنگی کی کمی — ڈویلپر git fetch نہیں کرتا اور develop کو اپ ڈیٹ نہیں کرتا، جس سے حتمی انضمام میں تنازعات پیدا ہوتے ہیں۔

ان مسائل سے بچنے کا بہترین طریقہ پروجیکٹ کے آغاز میں کام کے قواعد پر متفق ہونا اور CI/CD پائپ لائن میں خودکار جانچوں کا استعمال کرنا ہے۔

Feature Branch کے ساتھ کام کرنے کے لیے کمانڈ کی مثالیں

ایک عملی منظر نامے پر غور کریں: ایک ڈویلپر موبائل ایپ میں ایک نئی تصدیقی خصوصیت شروع کرتا ہے۔ وہ ایک feature برانچ بناتا ہے، کوڈ پر کام کرتا ہے اور Pull Request کے ساتھ کام مکمل کرتا ہے۔

# develop کو اپ ڈیٹ کریں اور feature برانچ بنائیں
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# فیچر پر کام: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# feature برانچ کو سرور پر push کریں
git push origin feature/add-login-screen

# develop کے ساتھ ہم آہنگ کریں (rebase)
git fetch origin develop
git rebase origin/develop

# PR کی منظوری کے بعد: مقامی develop کو اپ ڈیٹ کریں اور برانچ حذف کریں
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

کمانڈ git branch -d برانچ کو صرف اس وقت حذف کرتی ہے جب اس کی تبدیلیاں مکمل طور پر ضم ہو چکی ہوں۔ اگر برانچ ضم نہیں ہوئی ہے، Git جبری حذف کرنے کے لیے git branch -D استعمال کرنے کا مشورہ دے گا — اس فلیگ کو احتیاط سے استعمال کریں۔

Feature برانچ میں جانچوں کا آٹومیشن

PR بنانے سے پہلے ہر feature برانچ کے لیے CI/CD پائپ لائن چلنی چاہیے۔ یہ کوڈ کے دوسرے ڈویلپرز کے جائزے میں جانے سے پہلے ابتدائی مرحلے میں مسائل کا پتہ لگانے میں مدد کرتا ہے۔

# feature برانچ کی جانچ کے لیے GitHub Actions
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

پائپ لائن جانچتی ہے کہ کوڈ کمپائل ہوتا ہے، ٹیسٹ پاس ہوتے ہیں اور کوڈ کا انداز ٹیم کے معیارات پر پورا اترتا ہے۔ تمام جانچیں پاس کرنے کے بعد ہی Pull Request بنایا جا سکتا ہے۔