Git میں Develop Branch — یہ کیا ہے، مقصد اور کام کرنے کے اصول

Git میں Develop Branch کیا ہے

Develop Branch (ڈویلپمنٹ برانچ) Git Flow میں ایک طویل مدتی برانچ ہے جو تمام ڈویلپرز سے کوڈ انٹیگریشن کے لیے مرکزی مرکز کے طور پر کام کرتی ہے۔ ڈویلپمنٹ مکمل ہونے اور کوڈ ریویو کے بعد feature branches اس میں merge کی جاتی ہیں۔

develop میں کوڈ ہمیشہ ریلیز بنانے کے لیے تیار حالت میں ہوتا ہے، اگرچہ ابھی تک پروڈکشن میں ڈپلائے نہیں کیا گیا۔ اس کا مطلب ہے کہ develop کی تمام خصوصیات ریویو، ٹیسٹنگ اور انٹیگریشن جانچ سے گزر چکی ہیں، لیکن ابھی بھی اپنے ریلیز سائیکل کا انتظار کر رہی ہیں۔

main کے برعکس، جہاں ہر کوڈ ورژن ایک ریلیز ہے، develop میں تبدیلیوں کا ایک مسلسل سلسلہ ہوتا ہے۔ feature branches کے merge ہونے پر develop میں commits ظاہر ہوتے ہیں، جو دن میں کئی بار ہو سکتا ہے۔

Vincent Driessen، 2010 کے مطابق، develop ایک کامیاب برانچنگ ماڈل کا اہم عنصر ہے، کیونکہ یہ ڈرافٹ کام کو ریلیز کے لیے تیار ورژن سے الگ کرتا ہے۔

develop اور main branch میں فرق

develop اور main کے درمیان فرق کو سمجھنا مناسب Git Flow ورک فلو کے لیے بہت اہم ہے۔ یہ برانچز مختلف کام انجام دیتی ہیں اور استحکام کے مختلف تقاضے رکھتی ہیں۔

develop اور main میں تقسیم ٹیم کو پروڈکشن ورژن کے استحکام کو خطرے میں ڈالے بغیر مسلسل نیا کوڈ ضم کرنے کی اجازت دیتی ہے۔ ڈویلپرز سرکاری ریلیز سے پہلے بھی، PR کی منظوری کے فوراً بعد develop میں اپنا کوڈ دیکھ سکتے ہیں۔

Git Flow میں develop کا کردار

Git Flow ماڈل میں، develop feature branches (تبدیلیوں کا ذریعہ) اور release branches (ریلیز کی تیاری) کے درمیان مرکزی مقام رکھتا ہے۔ اس درجہ بندی کو سمجھنا مؤثر برانچنگ کی بنیاد ہے۔

• Feature → Develop — ہر مکمل خصوصیت کوڈ ریویو کے ساتھ Pull Request کے ذریعے develop میں merge کیا جاتا ہے۔
• Develop → Release — جب ریلیز کے لیے کافی تبدیلیاں جمع ہو جاتی ہیں، develop سے release branch بنائی جاتی ہے۔
• Release → Main + Develop — حتمی تیاری کے بعد، release branch کو main (ریلیز) اور واپس develop (بگ فکس) میں merge کیا جاتا ہے۔
• Hotfix → Main + Develop — اہم فکس main سے بنائے جاتے ہیں اور دونوں برانچز میں merge کیے جاتے ہیں۔

یہ ڈھانچہ اس بات کو یقینی بناتا ہے کہ develop میں ہمیشہ تمام نئی خصوصیات کے ساتھ تازہ ترین کوڈ ہو، جبکہ main میں صرف تصدیق شدہ پروڈکشن کوڈ ہو۔ یہ App Store اور Google Play میں طویل ریویو سائیکل والے موبائل پروجیکٹس کے لیے خاص طور پر اہم ہے۔

دیگر Git Flow برانچز کے ساتھ develop کا تعلق

Develop feature، release اور hotfix branches کے درمیان مرکزی ربط کے طور پر کام کرتا ہے۔ merge کی سمتوں کو سمجھنا تصادم اور commit کے ضیاع کو روکنے کے لیے ضروری ہے۔

develop میں کوڈ کوالٹی کے تقاضے

develop میں کوڈ کوالٹی اعلیٰ ہونی چاہیے، لیکن مطلق نہیں۔ main کے برعکس، جہاں ہر غلطی کا مطلب فوری hotfix ہے، develop معمولی خامیوں کی اجازت دیتا ہے جو ریلیز سے پہلے ٹھیک کر دی جائیں گی۔

develop میں merge کرنے سے پہلے کوڈ کے لیے کم از کم تقاضے:

• کمپائلیشن — کوڈ بغیر غلطیوں کے کمپائل ہونا چاہیے۔ develop میں ٹوٹا ہوا build پوری ٹیم کا کام روک دیتا ہے۔
• یونٹ ٹیسٹ — تمام موجودہ ٹیسٹ پاس ہونے چاہئیں۔ نئے کوڈ کو کم از کم 70% ٹیسٹ سے کور کیا جانا چاہیے۔
• کوڈ اسٹائل — کوڈ کو ٹیم کے قبول شدہ فارمیٹنگ اور نام رکھنے کے معیارات پر عمل کرنا چاہیے۔
• کوئی deprecated API نہیں — نئے کوڈ میں فرسودہ طریقوں کے استعمال کی اجازت نہیں ہے۔

CI/CD پائپ لائن میں خودکار جانچ develop میں ہر push پر چلنی چاہیے۔ اگر build ٹوٹ جاتا ہے، تو ذمہ دار ڈویلپر کو ایک گھنٹے کے اندر مسئلہ حل کرنا ہوگا یا اپنا commit واپس لینا ہوگا۔

develop کے لیے CI/CD جانچ

develop کے لیے GitHub Actions ترتیب دینا اس بات کو یقینی بناتا ہے کہ ہر PR merge کرنے سے پہلے خودکار جانچ سے گزرے۔ ایک عام پائپ لائن میں build، ٹیسٹ اور لِنٹنگ شامل ہیں۔

# GitHub Actions — merge کے بعد develop کی جانچ
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

develop میں merge کے قوانین

develop میں merge کرنا انٹیگریشن برانچ کے استحکام کو برقرار رکھنے کے لیے سخت قوانین پر عمل کرنا چاہیے۔ ان قوانین کی خلاف ورزی تصادم، ٹوٹے ہوئے builds اور ٹیم کے وقت کے ضیاع کا سبب بنتی ہے۔

• صرف Pull Request کے ذریعے — develop میں براہ راست push ممنوع ہے۔ تمام تبدیلیاں کوڈ ریویو سے گزرتی ہیں۔
• کم از کم ایک منظوری — PR کو کام میں شامل نہ ہونے والے کم از کم ایک ڈویلپر سے منظوری لینی چاہیے۔
• Squash merge — صاف تاریخ کے لیے develop میں merge کرتے وقت تمام feature branch commits کو ایک میں یکجا کرنے کی سفارش کی جاتی ہے۔
• PR تازہ ترین ہو — merge کرنے سے پہلے، PR تازہ ترین develop commit (rebase یا merge) کے مطابق اپ ڈیٹ ہونا چاہیے۔

PR تازہ ترین ہو کا قاعدہ خاص طور پر اہم ہے۔ اگر کوئی feature branch ایک ہفتہ پہلے بنائی گئی تھی اور develop 50 commits آگے بڑھ گیا ہے، تو براہ راست merge تصادم کا سبب بن سکتا ہے جسے develop کی بجائے PR کے سیاق و سباق میں حل کرنا بہتر ہے۔

غلط merge سے develop کا تحفظ

برانچ پروٹیکشن رولز GitHub، GitLab یا Bitbucket سطح پر ترتیبات ہیں جو develop میں غلط تبدیلیوں کو روکتی ہیں۔ وہ یقینی بناتے ہیں کہ حادثاتی push بھی انٹیگریشن برانچ کو نہ توڑے۔

develop کے لیے تجویز کردہ حفاظتی اصول:

• Pull request لازمی — develop میں براہ راست push ممنوع کریں۔ تمام تبدیلیاں صرف PR کے ذریعے۔
• منظوری لازمی — PR merge کرنے سے پہلے کم از کم 1-2 منظوری۔
• اسٹیٹس چیک لازمی — اگر CI/CD پائپ لائن پاس نہیں ہوئی تو merge بلاک کریں۔
• تازہ کاری لازمی — merge کرنے سے پہلے PR برانچ develop کے مطابق اپ ڈیٹ ہونی چاہیے۔
• Push رسائی محدود کریں — develop میں push کے حقوق صرف سینئر ڈویلپرز تک محدود کریں۔

develop تحفظ ترتیب دینے میں 10 منٹ لگتے ہیں لیکن ٹوٹی ہوئی انٹیگریشن برانچ سے متعلق ہفتوں کے ڈاؤن ٹائم کو روکتا ہے۔ ملٹی پلیٹ فارم ٹیموں والے موبائل پروجیکٹس کے لیے، یہ خاص طور پر متعلقہ ہے۔

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

ایک عام ڈویلپر کے دن پر غور کریں: صبح وہ develop کو اپ ڈیٹ کرتا ہے، ایک نئی feature branch بناتا ہے، اور کام مکمل کرنے کے بعد تبدیلیوں کو واپس develop میں merge کرتا ہے۔

# صبح develop sync
git checkout develop
git pull origin develop

# develop سے نئی feature branch بنانا
git checkout -b feature/add-push-notifications

# خصوصیت پر کام...
git add . && git commit -m "Add FCM integration"

# ڈویلپمنٹ کے دوران develop اپ ڈیٹ کرنا
git fetch origin develop
git rebase origin/develop

# PR منظوری کے بعد — لوکل develop اپ ڈیٹ کریں
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

develop میں git pull کمانڈ ایک ساتھ دو کام انجام دیتی ہے: git fetch (سرور سے نئے commits لاتا ہے) اور git merge (انہیں لوکل برانچ کے ساتھ merge کرتا ہے)۔ develop کے لیے، یہ معیاری ہم آہنگی کا طریقہ ہے۔

ٹوٹے ہوئے merge کے بعد develop کو بحال کرنا

اگر build توڑنے والا کوڈ develop میں آ جائے تو فوری کارروائی کرنی چاہیے۔ develop کے ڈاؤن ٹائم کا ہر گھنٹہ پوری ڈویلپمنٹ ٹیم کے لیے مسدود کام ہے۔

اگر build توڑنے والا کوڈ develop میں آ جائے تو مسئلہ پیدا کرنے والی تبدیلیوں کو کالعدم کرنے والا نیا commit بنانے کے لیے git revert استعمال کریں۔ develop میں git reset استعمال نہ کریں — یہ تاریخ کو دوبارہ لکھتا ہے جو دوسرے ٹیم ممبران کے پاس پہلے سے موجود ہے۔

# مسئلہ والا commit تلاش کرنا
git log --oneline develop

# revert کے ذریعے commit منسوخ کرنا (محفوظ)
git revert a1b2c3d

# ریموٹ develop میں فکس بھیجنا
git push origin develop

# کسی مخصوص commit میں تبدیلیاں دیکھنا
git show a1b2c3d --stat