مرج (Merge) — یہ کیا ہے، merge کیسے کام کرتا ہے اور مرجنگ کی حکمت عملیاں

Git میں مرج کیا ہے

مرج (Merge) git merge کمانڈ ہے جو مخصوص برانچ سے تبدیلیوں کو موجودہ برانچ میں یکجا کرتی ہے۔ Git مشترکہ آباؤاجداد (بیس کمٹ) ڈھونڈتا ہے، آباؤاجداد کے نسبت ہر برانچ کے diff کا حساب لگاتا ہے، اور تبدیلیوں کا مشترکہ سیٹ پر مشتمل ایک مرج کمٹ بناتا ہے۔ نتیجہ یہ ہوتا ہے کہ ہدف برانچ مرج کی گئی برانچ سے تمام تبدیلیاں حاصل کر لیتی ہے۔

سینٹیکس: ہدف برانچ (مثلاً main) پر ہوتے ہوئے، git merge feature چلائیں۔ اگر کوئی تنازع نہ ہو تو Git خود بخود ایک مرج کمٹ بنا دیتا ہے۔ ڈیفالٹ مرج کمٹ پیغام ہے: «Merge branch 'feature' into main»۔ آپ -m فلیگ استعمال کر کے پیغام تبدیل کر سکتے ہیں یا کھلے ایڈیٹر میں اسے ترمیم کر سکتے ہیں۔

مرج ایک غیر تباہ کن عمل ہے۔ rebase کے برعکس، merge موجودہ کمٹس کو نہیں چھوتا: وہ ایک ہی ہیش، مصنفین اور تاریخیں برقرار رکھتے ہیں۔ یہ merge کو ان برانچز کو مرج کرنے کا واحد محفوظ طریقہ بناتا ہے جن پر ایک ساتھ متعدد ڈویلپر کام کر رہے ہوں۔ اگر کچھ غلط ہو جائے تو merge کو git merge --abort سے منسوخ کیا جا سکتا ہے۔

# ہدف برانچ پر سوئچ کریں
git checkout main

# فیچر برانچ مرج کریں
git merge feature

# نتیجہ — دو والدین کے ساتھ مرج کمٹ
git log --oneline --graph

# اپنی مرضی کے پیغام سے مرج
git merge feature -m "feat: integrate authentication module"

مرج کی اقسام: regular، squash، fast-forward

Git تین مرجنگ موڈز کو سپورٹ کرتا ہے جو مطلوبہ نتیجے کی بنیاد پر منتخب کیے جاتے ہیں۔ ریگولر مرج (ڈیفالٹ) ایک مرج کمٹ بناتا ہے۔ Squash merge فیچر برانچ کے تمام کمٹس کو ایک میں یکجا کرتا ہے۔ Fast-forward اگر ممکن ہو تو کمٹ بنائے بغیر برانچ پوائنٹر کو آگے بڑھاتا ہے۔ موڈ کا انتخاب ٹیم کے ورک فلو اور ہسٹری کے قواعد پر منحصر ہے۔

ریگولر مرج (--no-ff) — مرج کمٹ بناتا ہے چاہے مرج کو fast-forward کے طور پر کیا جا سکتا ہو۔ main برانچ کے لیے سفارش کی جاتی ہے: مرج کمٹ واضح طور پر فیچر انٹیگریشن پوائنٹ کو نشان زد کرتا ہے اور ایک مرج کمٹ revert کے ساتھ فیچر برانچ کی تمام تبدیلیوں کو آسانی سے واپس لینے کی اجازت دیتا ہے۔ GitHub PR کو Merge بٹن سے مرج کرتے وقت ڈیفالٹ طور پر اس موڈ کا استعمال کرتا ہے۔

Squash merge (--squash) — فیچر برانچ کے تمام کمٹس کو ہدف برانچ میں ایک اکائی کمٹ میں جمع کرتا ہے۔ مفید جب فیچر برانچ کی ڈرافٹ ہسٹری main کو آلودہ نہ کرے۔ خامی: اصل کمٹس سے تعلق ختم ہو جاتا ہے — یہ نہیں دیکھا جا سکتا کہ فیچر مرحلہ وار کیسے تیار ہوا۔ GitHub PR میں «Squash and merge» منتخب کرنے پر اس موڈ کا استعمال کرتا ہے۔

Fast-forward (--ff) — اگر فیچر برانچ کے جدا ہونے کے بعد ہدف برانچ میں کوئی نیا کمٹ نہیں ہے تو Git مرج کمٹ بنائے بغیر پوائنٹر کو آگے بڑھا دیتا ہے۔ ہسٹری لکیری رہتی ہے۔ --no-ff فلیگ مرج کمٹ کو مجبور کرتا ہے، جبکہ --ff-only اگر fast-forward ممکن نہ ہو تو خرابی دے گا۔

# مرج کمٹ مجبور کریں (main کے لیے سفارش کردہ)
git merge --no-ff feature

# Squash merge — تمام کمٹس ایک میں
git merge --squash feature
git commit -m "feat: add authentication"

# صرف ممکن ہو تو fast-forward
git merge --ff-only feature

# تنازع والے مرج کو منسوخ کریں
git merge --abort

Git مرجنگ حکمت عملیاں

مرجنگ حکمت عملیاں الگورتھم کا تعین کرتی ہیں جو Git تبدیلیوں کو یکجا کرنے کے لیے استعمال کرتا ہے۔ ہر حکمت عملی مختلف منظرناموں کے لیے موزوں ہے۔ Git خود بخود مناسب حکمت عملی منتخب کرتا ہے، لیکن ڈویلپر --strategy فلیگ استعمال کر کے اسے واضح طور پر مشخص کر سکتے ہیں۔ حکمت عملیوں کو سمجھنے سے پیچیدہ مرجز میں Git کے رویے کی پیش گوئی کرنے میں مدد ملتی ہے۔

Recursive — دو برانچز کو مرج کرنے کے لیے ڈیفالٹ حکمت عملی۔ Git مشترکہ آباؤاجداد ڈھونڈتا ہے، ہر برانچ میں تبدیلیوں کا حساب لگاتا ہے، اور انہیں مرج کرتا ہے۔ اگر مشترکہ آباؤاجداد مل جائے تو recursive فائل کی دوبارہ نامزدگی اور اضافے کو صحیح طریقے سے ہینڈل کرتا ہے۔ تنازعات کے دوران recursive اضافی اختیارات استعمال کر سکتا ہے: ours (خود بخود ہمارا ورژن منتخب کریں) اور theirs (ان کا ورژن منتخب کریں)۔

Octopus — ایک ساتھ دو سے زیادہ برانچز کو مرج کرنے کے لیے: git merge feature1 feature2 feature3۔ Octopus تنازع حل کرنے کی حمایت نہیں کرتا — کمانڈ کو کال کرنے سے پہلے تمام تنازعات حل کیے جانے چاہئیں۔ یہ شاذ و نادر ہی استعمال ہوتا ہے، بنیادی طور پر متعدد آزاد برانچز کو مرج کرنے کے لیے جو تنازع نہ کرنے کی ضمانت دی گئی ہوں (مثلاً مختلف ماڈیول)۔

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

مرج تنازعات کا حل

مرج تنازع اس وقت ہوتا ہے جب کسی فائل کی ایک ہی سطروں کو دونوں برانچز میں مختلف طریقے سے تبدیل کر دیا جائے۔ Git خود بخود تعین نہیں کر سکتا کہ کون سا ورژن درست ہے اور مرج کو روک دیتا ہے۔ تنازع اس وقت بھی پیدا ہو سکتا ہے جب کسی فائل کا ایک برانچ میں نام تبدیل کیا جائے اور دوسری میں ترمیم کی جائے، یا جب ایک ہی فائل کو ایک ساتھ حذف اور ترمیم کیا جائے۔

حل کا عمل: Git تنازع والی فائلوں کو نشانات سے نشان زد کرتا ہے۔ فائل میں <<<<<<< HEAD (ہمارا ورژن)، ======= (جدا کرنے والا) اور >>>>>>> feature (ان کا ورژن) والے حصے نظر آتے ہیں۔ ڈویلپر دستی طور پر تنازع والے حصے میں ترمیم کرتا ہے، دونوں ورژنز سے مطلوبہ سطریں منتخب کرتا ہے، نشانات ہٹاتا ہے، فائل محفوظ کرتا ہے اور git add سے انڈیکس میں شامل کرتا ہے۔

بصری تنازع حل کے لیے Git mergetool کو سپورٹ کرتا ہے — ایک بیرونی موازنہ کا آلہ۔ مشہور mergetool: Meld، KDiff3، Beyond Compare، VS Code (بلٹ ان تنازع ایڈیٹر)۔ Mergetool تین پینل دکھاتا ہے: ہمارا ورژن، ان کا ورژن اور نتیجہ۔ ڈویلپر بصری طور پر کوڈ بلاکس کو حتمی فائل میں شامل کرنے کے لیے منتخب کرتا ہے۔

# مرج شروع کریں اور تنازع کا پتہ لگائیں
git merge feature
# تنازع (مواد): src/main.swift میں مرج تنازع

# تنازع والی فائلیں چیک کریں
git status

# بصری mergetool کھولیں
git mergetool

# حل کے بعد — add اور commit
git add src/main.swift
git commit

# مرج منسوخ کریں
git merge --abort

rebase کی بجائے merge کب منتخب کریں

Merge، rebase پر ترجیح رکھتا ہے کئی اہم حالات میں۔ پہلا: دوسرے ڈویلپرز کے لیے قابل رسائی عوامی برانچز کے ساتھ کام کرتے وقت۔ Merge ہسٹری کو دوبارہ نہیں لکھتا، اس لیے ساتھی محفوظ طریقے سے مطابقت پذیر ہو سکتے ہیں۔ عوامی برانچ پر rebase کرنے سے مختلف ہسٹری بنتی ہے اور ان سب کے لیے تنازعات پیدا ہوتے ہیں جن کے پاس پہلے سے پرانے کمٹس ہیں۔

دوسری صورت: فیچر برانچ مکمل کرتے وقت۔ زیادہ تر ٹیمیں main میں merge (--no-ff فلیگ کے ساتھ) کو ترجیح دیتی ہیں تاکہ فیچر انٹیگریشن کے لمحے کو ریکارڈ کیا جا سکے۔ یہ ہسٹری نیویگیشن کو آسان بناتا ہے اور مرج کمٹ کے ایک git revert سے پورے فیچر کو آسانی سے واپس لینے کی اجازت دیتا ہے۔ GitHub Flow ڈیفالٹ طور پر تین merge اختیارات پیش کرتا ہے: سادہ merge، squash merge اور rebase merge۔

تیسری صورت: نظرثانی شدہ پل ریکویسٹ کے ساتھ کام کرتے وقت۔ GitHub اور GitLab مختلف اختیارات کے ساتھ ایک merge بٹن پیش کرتے ہیں۔ Merge (Create a merge commit) — مرج کمٹ کے ساتھ مکمل ہسٹری۔ Squash and merge — ڈیولپمنٹ کی تفصیلات کے بغیر صاف ہسٹری۔ Rebase and merge — مرج کمٹ کے بغیر لکیری ہسٹری، لیکن کمٹ دوبارہ لکھنے کے ساتھ۔ انتخاب ٹیم کے قواعد پر منحصر ہے۔

• عوامی برانچز (main, develop) — صرف merge، کبھی rebase نہیں۔
• PR مکمل کرنا — انٹیگریشن پوائنٹ نشان زد کرنے کے لیے --no-ff کے ساتھ merge۔
• دوسروں کے کمٹ والی برانچز — merge دوسروں کے کام کو دوبارہ نہیں لکھتا۔
• ریلیز سے پہلے — merge زیادہ محفوظ ہے کیونکہ اس میں کم خطرات ہیں۔
• مشترکہ برانچ — اگر متعدد ڈویلپر ایک برانچ پر کام کریں تو merge لازمی ہے۔

برانچ مرجنگ کے بہترین طریقے

پہلا قاعدہ: مرج کرنے سے پہلے ہمیشہ ہدف برانچ کے تازہ ترین ورژن پر رہیں۔ فیچر برانچ کو مرج کرنے سے پہلے git checkout main && git pull چلائیں۔ اس سے تنازعات کم سے کم ہوتے ہیں اور اس بات کی ضمانت ملتی ہے کہ مرج کمٹ میں تمام تازہ ترین تبدیلیاں شامل ہیں۔ اگر ہدف برانچ کافی آگے بڑھ گئی ہے تو پہلے فیچر برانچ کے اندر git merge main چلائیں تاکہ اس کے سیاق و سباق میں تنازعات حل کیے جا سکیں۔

دوسرا قاعدہ: مرج کے بعد کوڈ کی جانچ کریں۔ مرج رویہ تبدیل کر سکتا ہے چاہے کوئی تنازع نہ ہوا ہو۔ CI/CD پائپ لائن کو پروڈکشن میں بھیجنے سے پہلے مرج کمٹ پر ٹیسٹ چلانے چاہئیں۔ کچھ ٹیمیں مرج گیمز استعمال کرتی ہیں — لازمی جانچیں جو پاس ہونے تک مرج کو روکتی ہیں۔

تیسرا قاعدہ: مرج کمٹس کو دستاویز کریں۔ معیاری پیغام «Merge branch 'feature' into main» زیادہ مفید نہیں ہے۔ سفارش کی جاتی ہے کہ کیا مرج کیا گیا اس کی وضاحت شامل کریں: «Merge authentication module: login, registration, password recovery»۔ اس سے ہسٹری کا تجزیہ اور ریگریشن کی تلاش آسان ہو جاتی ہے۔ بڑے منصوبوں میں، مرج کمٹس خود بخود PR کے عنوان سے تیار ہوتے ہیں۔

• تازہ کاری — مرج کرنے سے پہلے یقینی بنائیں کہ ہدف برانچ اپ ڈیٹ ہے (git pull)۔
• جانچ — CI/CD کو نتیجے میں ملنے والے مرج کمٹ پر ٹیسٹ چلانے چاہئیں۔
• وضاحتی پیغامات — مرج کمٹ میں متعین کریں کہ کون سی فیچر مرج کی گئی۔
• تعدد — فیچر برانچز کو جتنی جلدی اور جتنی بار ممکن ہو مرج کریں (زیادہ سے زیادہ ایک ہفتہ)۔
• واپس لینا — مرج کمٹ کا git revert پوری فیچر کو واپس لے لیتا ہے۔