Git میں Main اور Master Branch: یہ کیا ہے اور آپ کو مرکزی شاخ کی ضرورت کیوں ہے

Git میں Main / Master Branch کیا ہے

Main Branch (یا Master — ذخیرہ کی ترتیبات پر منحصر) ڈیفالٹ شاخ ہے جو کسی بھی Git ذخیرہ کو شروع کرتے وقت بنائی جاتی ہے۔ یہ پروجیکٹ کی مرکزی شاخ ہے اور اس میں کوڈ ہوتا ہے جو پروڈکشن میں ڈپلائے کرنے کے لیے تیار ہے۔

develop کے برعکس، جہاں نئی خصوصیات کے ساتھ روزانہ کا کام جاری رہتا ہے، main پروجیکٹ کا شوکیس ہے۔ main میں کوڈ کا ہر ورژن ایک مکمل چکر سے گزرا ہے: feature شاخ میں ڈویلپمنٹ، develop میں انضمام، release شاخ میں ریلیز کی تیاری اور حتمی جانچ۔ اس کے بعد ہی تبدیلیاں main تک پہنچتی ہیں۔

اہم اصول: main ہمیشہ مستحکم ہونا چاہیے۔ اگر main میں کوئی خرابی پائی جاتی ہے، تو اس کا مطلب ہے کہ فوری hotfix کی ضرورت ہے۔ لہذا، پیشہ ورانہ پروجیکٹس میں، main کو شاخ کے تحفظ کے قواعد کے ذریعے حادثاتی تبدیلیوں سے بچایا جاتا ہے۔

Git Book کے مطابق، main منفرد خصوصیات والی کوئی خاص شاخ نہیں ہے، بلکہ ایک کمٹ کا عام حوالہ ہے جسے روایت کے مطابق مرکزی سمجھا جاتا ہے۔ Git نظام کی سطح پر main اور کسی بھی دوسری شاخ میں فرق نہیں کرتا۔

master سے main میں منتقلی

تاریخی طور پر، Git میں ڈیفالٹ شاخ کو master کہا جاتا تھا۔ جون 2020 میں، Black Lives Matter تحریک نے IT صنعت میں master اور slave کی اصطلاحات کی طرف توجہ مبذول کرائی۔ GitHub نے ڈیفالٹ شاخ کے لیے main کی اصطلاح میں منتقلی کا اعلان کیا۔

اکتوبر 2020 سے، GitHub پر تمام نئے ذخیرے main شاخ کے ساتھ بنائے جاتے ہیں۔ GitLab اور Bitbucket نے بھی ڈیفالٹ نام کے طور پر main کے لیے حمایت نافذ کی۔ Git 2.28 (جولائی 2020) نے ڈیفالٹ شاخ کا نام ترتیب دینے کے لیے init.defaultBranch آپشن شامل کیا۔

تکنیکی طور پر، موجودہ شاخ کا نام master سے main میں تبدیل کرنا ایک سادہ عمل ہے۔ اہم چیلنج CI/CD کنفیگریشنز، دستاویزات اور ڈویلپرز کے مقامی ذخیروں میں تمام حوالوں کو اپ ڈیٹ کرنا ہے۔

موجودہ ذخیرے میں شاخ کا نام تبدیل کرنے کے لیے، چلائیں:

# مقامی طور پر master کا نام main رکھنا
git branch -m master main

# ریموٹ ذخیرہ اپ ڈیٹ کرنا
git push -u origin main

# سرور پر پرانے master کو حذف کرنا
git push origin --delete master

# سرور پر HEAD اپ ڈیٹ کرنا
# (GitHub ویب انٹرفیس کے ذریعے: Settings → Branches → Default branch)

Git Flow اور GitHub Flow میں main کا کردار

Git Flow اور GitHub Flow main شاخ کے کردار کو مختلف طریقے سے متعین کرتے ہیں۔ ماڈل کا انتخاب ٹیم کے سائز، ریلیز کی تعدد اور کوڈ کے استحکام کی ضروریات پر منحصر ہے۔

موبائل ڈویلپمنٹ کے لیے، Git Flow معیار ہے، کیونکہ App Store اور Google Play پر ایپ شائع کرنے کے مقررہ ریلیز سائیکل ہوتے ہیں۔ GitHub Flow ان ویب پروجیکٹس کے لیے زیادہ موزوں ہے جنہیں دن میں کئی بار ڈپلائے کیا جا سکتا ہے۔

GitHub Flow — آسان طریقہ

GitHub Flow میں، کوئی develop شاخ نہیں ہے۔ تمام feature شاخیں براہ راست main سے بنائی جاتی ہیں، اور مکمل ہونے کے بعد Pull Request کے ذریعے واپس ضم کر دی جاتی ہیں۔ main میں ہر انضمام خود بخود پروڈکشن میں ڈپلائمنٹ کو متحرک کرتا ہے۔ اس ماڈل کے لیے اعلی سطح کی جانچ آٹومیشن اور ٹیم کے نظم و ضبط کی ضرورت ہوتی ہے۔

GitHub Flow میں، کوئی develop شاخ نہیں ہے۔ تمام feature شاخیں براہ راست main سے بنائی جاتی ہیں، اور مکمل ہونے کے بعد Pull Request کے ذریعے واپس ضم کر دی جاتی ہیں۔ main میں ہر انضمام خود بخود پروڈکشن میں ڈپلائمنٹ کو متحرک کرتا ہے۔ اس ماڈل کے لیے اعلی سطح کی جانچ آٹومیشن اور ٹیم کے نظم و ضبط کی ضرورت ہوتی ہے۔

main شاخ کا تحفظ

main کے لیے شاخ کا تحفظ کسی بھی تجارتی پروجیکٹ میں لازمی ترتیب ہے۔ اس کے بغیر، ایک حادثاتی push نامکمل کوڈ پروڈکشن میں بھیج سکتا ہے یا تمام صارفین کے لیے کام کرنے والی ایپلیکیشن کو توڑ سکتا ہے۔

• Require pull request — main میں براہ راست push ممنوع ہے۔ تمام تبدیلیاں جائزے کے ساتھ PR کے ذریعے۔
• Require approvals — main میں ضم کرنے کے لیے کم از کم 2 منظوریں (اگر کوئی جائزہ لینے والا کچھ چوک جائے)۔
• Require status checks — ضم کرنے سے پہلے تمام CI/CD جانچیں کامیاب ہونی چاہئیں۔
• Require up-to-date — PR تازہ ترین main کمٹ پر مبنی ہونا چاہیے۔
• Include administrators — تحفظ ذخیرہ کے مالکان پر بھی لاگو ہوتا ہے۔
• Require signed commits — main میں تمام کمٹ GPG کلید سے دستخط شدہ ہونے چاہئیں۔

تمام چھ قواعد کو ترتیب دینا 10,000+ صارفین والے موبائل پروجیکٹس کے لیے معیار ہے۔ چھوٹے پروجیکٹس کے لیے، پہلے تین قواعد کافی ہیں۔

مختلف قسم کے پروجیکٹس کے لیے تحفظ کی سطحوں کا موازنہ

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

main میں ریلیز اور ٹیگز

ٹیگنگ main میں مخصوص کمٹ کے نامزد حوالے بنانے کا عمل ہے۔ ہر ٹیگ پروڈکشن میں جاری کردہ ایپلیکیشن کے ایک ورژن سے مطابقت رکھتا ہے۔ یہ ڈیبگنگ یا پیچ کے لیے کسی بھی پچھلی ریلیز پر فوری سوئچ کرنے کی اجازت دیتا ہے۔

موبائل ڈویلپمنٹ میں ٹیگ کے نام رکھنے کا معیار SemVer (سیمنٹک ورژننگ) ہے: v1.2.3، جہاں پہلا نمبر میجر ورژن (تبدیلیاں توڑنے والی)، دوسرا مائنر ورژن (نئی خصوصیات)، اور تیسرا پیچ (اصلاحات) ہے۔

release شاخ کو main میں ضم کرنے کے بعد ایک ٹیگ بنایا جاتا ہے۔ پھر اس کمٹ کو CI/CD میں بنایا جاتا ہے، دستخط کیا جاتا ہے اور ایپ اسٹور کو بھیجا جاتا ہے۔ اگر ٹیگ میں کوئی خرابی پائی جاتی ہے، تو اس ٹیگ سے hotfix شاخ بنائی جاتی ہے۔

# تشریح شدہ ریلیز ٹیگ بنانا
git tag -a v2.4.1 -m "Release version 2.4.1"

# سرور کو ٹیگ بھیجنا
git push origin v2.4.1

# ذخیرے میں تمام ٹیگز دیکھنا
git tag -l "v2.*"

# کسی مخصوص ٹیگ سے hotfix شاخ بنانا
git checkout -b hotfix/crash-fix v2.4.1

Git Flow شاخ کا درجہ بندی

Git Flow میں شاخ کے درجہ بندی کو سمجھنا باہمی تعاون سے ڈویلپمنٹ کو صحیح طریقے سے منظم کرنے کی بنیاد ہے۔ ہر شاخ کی قسم کا اپنا ماخذ، مقصد اور انضمام کے قواعد ہوتے ہیں۔

• Main (سطح 1) — بنیادی شاخ، صرف ریلیز ورژن رکھتی ہے۔ ذخیرہ شروع کرتے وقت بنائی جاتی ہے۔
• Develop (سطح 2) — پروجیکٹ شروع ہونے پر main سے بنائی جاتی ہے۔ تمام خصوصیات کا انضمام کوڈ رکھتی ہے۔
• Feature (سطح 3) — develop سے بنائی جاتی ہے۔ انفرادی خصوصیات کی علیحدہ ڈویلپمنٹ۔
• Release (سطح 2) — develop سے بنائی جاتی ہے۔ ایک مخصوص ریلیز کو لانچ کے لیے تیار کرنا۔
• Hotfix (سطح 2) — main سے بنائی جاتی ہے۔ پروڈکشن کی اہم خرابیوں کی فوری اصلاح۔

اہم قاعدہ: feature کبھی براہ راست main میں ضم نہیں ہوتی۔ feature → develop → release → main صحیح انضمام کا سلسلہ ہے۔ اس قاعدے کی خلاف ورزی پورے Git Flow ماڈل کے مقصد کو ختم کر دیتی ہے۔

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

ایک منظر نامے پر غور کریں: ٹیم نے ریلیز v2.5.0 کی تیاری مکمل کر لی ہے۔ release شاخ کا جائزہ لیا جا چکا ہے اور یہ main میں ضم ہونے کے لیے تیار ہے۔ انضمام کے بعد، ایک ٹیگ بنایا جاتا ہے اور ریلیز شائع کی جاتی ہے۔

# main پر سوئچ کرنا اور اپ ڈیٹ کرنا
git checkout main
git pull origin main

# تصدیق شدہ release شاخ کو ضم کرنا
git merge --no-ff release/2.5.0

# ریلیز ٹیگ بنانا
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# main اور ٹیگ سرور کو بھیجنا
git push origin main --tags

--no-ff جھنڈا (کوئی تیز آگے نہیں) انضمام کمٹ بنانے کی ضمانت دیتا ہے، چاہے انضمام صرف پوائنٹر کو ہلا کر کیا جا سکتا ہو۔ یہ معلومات محفوظ رکھتا ہے کہ تبدیلیاں release شاخ سے آئی ہیں، جس سے تاریخ کا تجزیہ آسان ہو جاتا ہے۔

main کے ذریعے hotfix کے ساتھ کام کرنا

اگر پروڈکشن میں کوئی اہم خرابی دریافت ہوتی ہے، تو عمل عام ریلیز سے مختلف ہوتا ہے۔ Hotfix main سے بنائی جاتی ہے، اور اصلاح کے بعد، اسے main اور develop دونوں میں ضم کیا جاتا ہے۔

اگر پروڈکشن میں کوئی اہم خرابی دریافت ہوتی ہے، تو عمل عام ریلیز سے مختلف ہوتا ہے۔ Hotfix main سے بنائی جاتی ہے، اور اصلاح کے بعد، اسے main اور develop دونوں میں ضم کیا جاتا ہے۔

# main سے hotfix شاخ بنانا
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# اصلاح اور کمٹ کرنا
git add src/fix/
git commit -m "Fix crash on login screen"

# hotfix کو واپس main میں ضم کرنا
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# hotfix کو develop میں بھی ضم کرنا
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# hotfix شاخ حذف کرنا
git branch -d hotfix/2.5.1-crash-fix