شاخوں کو ضم کرنا — یہ کیا ہے، ضم کرنے کے طریقے اور تنازعات کا حل

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

Git میں مرج دو یا زیادہ ترقیاتی تاریخوں کو ایک میں یکجا کرنے کا عمل ہے۔ جب کوئی ڈویلپر کسی شاخ کو ضم کرتا ہے، Git خود بخود مشترکہ آباؤاجداد (base commit) ڈھونڈتا ہے اور ایک نیا مرج commit تخلیق کرتا ہے جس میں دونوں شاخوں کی تبدیلیاں شامل ہوتی ہیں۔ Three-way merge ایک معیاری الگورتھم ہے جو تین حالتوں کا موازنہ کرتا ہے: مشترکہ آباؤاجداد، پہلی شاخ اور دوسری شاخ۔

مرج کا عمل git merge کمانڈ سے شروع ہوتا ہے۔ Git شاخوں کے انحراف کے مقام کا تعین کرتا ہے اور ماخذ شاخ سے ہدف شاخ پر ترتیب وار تبدیلیاں لاگو کرتا ہے۔ اگر تبدیلیاں تنازعہ نہ کریں، Git ترتیبات کے مطابق fast-forward انجام دیتا ہے یا merge commit تخلیق کرتا ہے۔ Fast-forward ایک منظرنامہ ہے جہاں ہدف شاخ ماخذ شاخ کے commits پر چلی جاتی ہے۔

# ہدف شاخ پر سوئچ کریں اور ضم کریں
git checkout main
git merge feature/payment-module

# واضح no-fast-forward کے ساتھ ضم کریں
git merge --no-ff feature/payment-module

# اگر تنازعات بہت پیچیدہ ہوں تو مرج منسوخ کریں
git merge --abort

--no-ff پرچم (no fast-forward) fast-forward ممکن ہونے پر بھی merge commit تخلیق کرنے پر مجبور کرتا ہے۔ یہ معلومات محفوظ رکھتا ہے کہ تبدیلیاں علیحدہ شاخ میں کی گئی تھیں۔ بہت سی ٹیمیں واضح طور پر شاخ بندی کی تاریخ برقرار رکھنے کے لیے اس طریقے کو ترجیح دیتی ہیں۔

شاخوں کو ضم کرنے کے طریقے

Git میں شاخوں کو ضم کرنے کی تین اہم حکمت عملیاں ہیں، ہر ایک مخصوص منظرنامے کے لیے موزوں ہے۔ حکمت عملی کا انتخاب ٹیم کی ثقافت اور پروجیکٹ کی تاریخ کی صفائی کی ضروریات پر منحصر ہے۔

Standard merge دو والدین کے ساتھ merge commit تخلیق کرتا ہے۔ مکمل تاریخ محفوظ رہتی ہے، لیکن شاخ بندی کا گراف زیادہ پیچیدہ ہو جاتا ہے۔ Squash merge فیچر شاخ کے تمام commits کو ایک میں جمع کرتا ہے اور ہدف شاخ پر لاگو کرتا ہے — تاریخ خطی اور صاف ہو جاتی ہے، لیکن درمیانی مراحل کی معلومات ضائع ہو جاتی ہیں۔

Rebase، اگرچہ مکمل مرج نہیں ہے، وہی نتیجہ حاصل کرتا ہے — ایک شاخ کی تبدیلیاں دوسری کے اوپر منتقل ہو جاتی ہیں۔ فرق یہ ہے کہ تاریخ دوبارہ لکھی جاتی ہے: فیچر شاخ کے commits ہدف شاخ کے تازہ ترین commit کے اوپر دوبارہ تخلیق ہوتے ہیں۔ یہ مکمل طور پر خطی تاریخ دیتا ہے، لیکن push کرتے وقت force push کی ضرورت ہوتی ہے۔

مرج میں تنازعات کو کیسے حل کریں

مرج تنازعہ اس وقت پیدا ہوتا ہے جب فائل کی ایک ہی سطروں کو دو شاخوں میں تبدیل کیا جائے۔ Git خود بخود تعین نہیں کر سکتا کہ کون سا ورژن رکھنا ہے اور ڈویلپر کی مداخلت کی ضرورت ہے۔ تنازعات فائلوں میں خصوصی مارکر کے ساتھ دکھائے جاتے ہیں: <<<<<<<، =======، >>>>>>>۔

تنازعہ حل کرنے کے عمل میں کئی مراحل شامل ہیں۔ پہلے، ڈویلپر متصادم فائل کھولتا ہے اور دستی طور پر مطلوبہ تبدیلیاں منتخب کرتا ہے۔ صرف ایک ورژن کا انتخاب نہیں کرنا، بلکہ دونوں تبدیلیوں کی منطق کو سمجھنا اور درست فیصلہ کرنا ضروری ہے۔ فائل میں ترمیم کرنے کے بعد، تنازعہ مارکر ہٹا دیے جاتے ہیں اور تبدیلیاں git add کے ذریعے staging area میں شامل کی جاتی ہیں۔

# متصادم فائلوں کی فہرست دیکھیں
git status

# mergetool شروع کریں (مثلاً VS Code، IntelliJ)
git mergetool

# تمام تنازعات حل کرنے کے بعد
git add .
git merge --continue

# یا مرج مکمل طور پر منسوخ کریں
git merge --abort

بصری مرج ٹولز کا استعمال تنازعات کے حل کو نمایاں طور پر تیز کرتا ہے۔ VS Code، IntelliJ IDEA اور GitKraken تین پینلز کے ساتھ انٹرفیس فراہم کرتے ہیں: موجودہ شاخ، آنے والی شاخ اور نتیجہ۔ git mergetool ٹول متصادم فائل کے لیے ترتیب شدہ ایڈیٹر خود بخود کھولتا ہے۔

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

مرج کی بجائے rebase کب استعمال کریں

Rebase اور merge تبدیلیوں کو یکجا کرنے کے دو طریقے ہیں، اور ان کے درمیان انتخاب اکثر ٹیموں میں بحث کا باعث بنتا ہے۔ Rebase تاریخ کو دوبارہ لکھ کر ایک شاخ کے commits کو دوسری کے اوپر منتقل کرتا ہے۔ Merge شاخ بندی کی تاریخ کو محفوظ رکھتے ہوئے ایک نیا merge commit تخلیق کرتا ہے۔ ہر طریقہ کے اپنے فوائد اور حدود ہیں۔

Rebase اس وقت موزوں ہے جب ڈویلپر اپنی مقامی فیچر شاخ پر کام کر رہا ہو اور Pull Request بنانے سے پہلے ایک صاف خطی تاریخ چاہتا ہو۔ Rebase کے بعد، تمام commits غیر ضروری merge commits کے بغیر ترتیب وار منظم ہو جاتے ہیں۔ تاہم، rebase کے لیے force push کی ضرورت ہوتی ہے اور یہ ان شاخوں پر لاگو نہیں ہوتا جن پر ایک ساتھ کئی افراد کام کرتے ہیں۔

• Rebase — ذاتی فیچر شاخوں کے لیے جہاں صاف تاریخ درکار ہو
• Merge — مشترکہ شاخوں اور ضم ہونے کے لمحے کو ریکارڈ کرنے کے لیے
• Squash — جب فیچر شاخ میں بہت سے چھوٹے ڈرافٹ commits ہوں

Git کا سنہری اصول: ان commits پر rebase استعمال نہ کریں جو پہلے ہی مشترکہ ذخیرے میں push کیے جا چکے ہیں۔ یہ یقینی بناتا ہے کہ مشترکہ شاخ میں تاریخ تبدیل نہ ہو اور دوسرے ڈویلپرز کو نقل شدہ یا گمشدہ commits کا سامنا نہ کرنا پڑے۔ فیچر شاخ کو مرکزی شاخ میں ضم کرنے کے لیے Pull Request کے ذریعے merge استعمال کریں۔

شاخوں کو ضم کرنے کے بہترین طریقے

صحیح مرج عمل مستحکم ترقی کی بنیاد ہے۔ جدید ٹیم ورک میں، ضم کرنا کنسول کے ذریعے نہیں، بلکہ GitHub پر Pull Request یا GitLab میں Merge Request کے ذریعے کیا جاتا ہے۔ PR کوڈ کا جائزہ، خودکار CI جانچوں سے گزرتا ہے اور اس کے بعد ہی مرکزی شاخ میں ضم کیا جاتا ہے۔

پہلا عمل — صرف تمام جانچیں پاس ہونے کے بعد ضم کریں۔ CI پائپ لائن کو پروجیکٹ بنانا چاہیے، ٹیسٹ چلانا چاہیے اور کوڈ کے معیار کی تصدیق کرنی چاہیے۔ اگر کم از کم ایک جانچ ناکام ہوتی ہے، مرج مسدود ہو جاتا ہے۔ جدید پلیٹ فارمز (GitHub، GitLab) میں بلٹ ان تحفظ ہے: branch protection rules CI ناکام ہونے پر خود بخود مرج کو مسدود کر دیتے ہیں۔

دوسرا عمل — کبھی بھی ٹوٹا ہوا کوڈ ضم نہ کریں۔ مرج سے پہلے، ڈویلپر کو یقینی بنانا چاہیے کہ اس کی تبدیلیاں بلڈ کو نہیں توڑتیں اور موجودہ فعالیت کو پیچھے نہیں دھکیلتیں۔ اس کے لیے خودکار ٹیسٹ اور کوڈ کا جائزہ موجود ہیں۔

تیسرا عمل — مرج کے بعد فیچر شاخوں کو صاف کریں۔ جو شاخ پہلے ہی ضم ہو چکی ہے اسے حذف کر دینا چاہیے۔ یہ الجھن اور ذخیرے میں بے ترتیبی کو روکتا ہے۔ GitHub PR ضم ہونے کے بعد خود بخود شاخ حذف کرنے کی تجویز دیتا ہے، اور ذخیرے کی ترتیبات خودکار حذف کے لیے ترتیب دی جا سکتی ہیں۔