مرج — یہ کیا ہے، انضمام کی اقسام اور کام کرنے کا طریقہ کار

مرج کیا ہے؟

مرج (انضمام) — Git میں ایک بنیادی آپریشن ہے جو ایک برانچ (ماخذ) سے دوسری برانچ (ہدف) میں تبدیلیوں کو یکجا کرتا ہے۔ انضمام کے نتیجے میں، ہدف برانچ ماخذ برانچ کے ان تمام کمٹ کو وصول کرتی ہے جو ابھی تک اس میں نہیں تھے۔ صورت حال پر منحصر ہے، Git تین مختلف طریقوں سے مرج انجام دے سکتا ہے۔

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

GitLab Flow کے مطابق، Git کے ساتھ کام کرنے والی 73% ٹیمیں مرج کمٹ استعمال کرتی ہیں۔ متبادل طریقے (ریبیس، اسکوا ش) ان ٹیموں کو پسند ہیں جو لکیری تاریخ پر مرکوز ہیں۔ حکمت عملی کا انتخاب ٹیم کے سائز، ریلیز کی تعدد اور منصوبے میں قبول شدہ کنونشنز پر منحصر ہے۔

مرج کب ضروری ہے

مرج اس وقت ضروری ہے جب ڈیولپر کسی فیچر پر کام ختم کر کے اسے develop یا main میں ضم کرنا چاہتا ہے۔ ایک عام منظر نامہ: ڈیولپر نے develop سے ایک فیچر برانچ بنائی، اس پر کئی دن کام کیا، اور اس دوران develop میں ٹیم کے دیگر اراکین کے نئے کمٹ آئے۔ انضمام سے پہلے، تبدیلیوں کو یکجا کرنا ضروری ہے — اور اس کے لیے مرج استعمال کیا جاتا ہے۔

مرج کے بغیر، Git میں ایک کوڈ بیس پر باہمی تعاون سے کام کرنا ناممکن ہے۔ جب بھی دو ڈیولپر بیک وقت ایک کوڈ بیس میں تبدیلیاں کرتے ہیں، ان کی برانچیں الگ ہو جاتی ہیں۔ مرج ڈیٹا کے نقصان کے بغیر ان تبدیلیوں کو واپس لانے کا واحد طریقہ ہے۔

Git میں انضمام کی اقسام

Git تین اقسام کے مرج کی حمایت کرتا ہے، ہر ایک اپنے منظر نامے کے لیے ڈیزائن کیا گیا ہے۔ انضمام کی قسم کا انتخاب کمٹ کی تاریخ، واپسی کی سہولت اور لاگ کی پڑھنے کی اہلیت کو متاثر کرتا ہے۔

فاسٹ فارورڈ مرج

فاسٹ فارورڈ اس وقت ہوتا ہے جب ہدف برانچ میں ماخذ برانچ بننے کے بعد سے کوئی نیا کمٹ نہ ہو۔ اس صورت میں، Git صرف ہدف برانچ کے پوائنٹر کو آگے، ماخذ برانچ کے آخری کمٹ پر منتقل کر دیتا ہے۔ تاریخ لکیری رہتی ہے، مرج کمٹ کے بغیر۔

# فاسٹ فارورڈ مرج: فیچر بننے کے بعد سے develop تبدیل نہیں ہوا
git checkout develop
git merge feature/new-login

# نتیجہ: develop پوائنٹر فیچر کے آخر میں چلا گیا
# کوئی مرج کمٹ نہیں بنایا گیا

فاسٹ فارورڈ قلیل مدتی برانچوں کے لیے آسان ہے جہاں ڈیولپر نے اکیلے کام کیا۔ لیکن اس طریقے میں ایک خامی ہے: برانچ کے وجود کی معلومات کھو جاتی ہے — تمام کمٹ ایسے لگتے ہیں جیسے براہ راست develop میں کیے گئے ہوں۔

تھری وے مرج

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

# --no-ff پرچم کے ساتھ جبری تھری وے مرج
git checkout develop
git merge --no-ff feature/new-login

# ڈیفالٹ پیغام کے ساتھ ایک مرج کمٹ بنایا گیا
# -m کے ذریعے اپنا پیغام سیٹ کر سکتے ہیں
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

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

اسکوا ش مرج

اسکوا ش مرج ماخذ برانچ کے تمام کمٹ کو ایک میں سکیڑتا ہے اور اسے ہدف پر لاگو کرتا ہے۔ فیچر کی تاریخ کھو جاتی ہے — تمام تبدیلیوں کے ساتھ ایک کمٹ برانچ میں آتا ہے۔ یہ اس وقت آسان ہے جب فیچر برانچ میں تفصیلی کمٹ مجموعی تاریخ میں قدر نہیں بڑھاتے۔

# اسکوا ش مرج: فیچر کے تمام کمٹ ایک میں سکیڑے گئے
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

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

Ours اور Theirs حکمت عملی

Ours اور Theirs — Git میں دو خاص مرج حکمت عملیاں ہیں۔ Ours ماخذ برانچ کی تبدیلیوں کو مکمل طور پر نظر انداز کرتا ہے، صرف وہی رکھتا ہے جو ہدف میں ہے۔ Theirs، اس کے برعکس، کسی بھی تنازع میں ماخذ برانچ کے ورژن کو قبول کرتا ہے۔ یہ حکمت عملی کوڈ کی بڑی مقدار کو ضم کرتے وقت مفید ہوتی ہیں جب پہلے سے معلوم ہو کہ کون سا ورژن غالب آنا چاہیے۔

مرج کیسے کام کرتا ہے

Git میں مرج میکانزم تین نکات کے موازنہ پر مبنی ہے: مشترکہ آباؤاجداد (مرج بیس)، ماخذ برانچ کی حالت اور ہدف برانچ کی حالت۔ Git مرج بیس ڈھونڈتا ہے — دونوں برانچوں میں مشترکہ آخری کمٹ — اور حساب لگاتا ہے کہ انحراف کے بعد ہر برانچ میں کیا تبدیلیاں آئیں۔

• مرحلہ 1 — Git مرج بیس کا تعین کرتا ہے: دونوں برانچوں میں موجود آخری کمٹ
• مرحلہ 2 — Git دو diff بناتا ہے: مرج بیس سے ماخذ تک اور مرج بیس سے ہدف تک
• مرحلہ 3 — Git تبدیلیوں کے دونوں سیٹوں کو مرج بیس پر لاگو کرنے کی کوشش کرتا ہے
• مرحلہ 4 — اگر تبدیلیاں متضاد نہ ہوں — مرج خود بخود مکمل ہو جاتا ہے
• مرحلہ 5 — اگر تنازع ہو — Git رک جاتا ہے اور حل طلب کرتا ہے

Git ایک تین طرفہ انضمام الگورتھم استعمال کرتا ہے جو نہ صرف دو موازنہ فائل ورژن بلکہ ان کے مشترکہ آباؤاجداد کو بھی مدنظر رکھتا ہے۔ اس کی بدولت، Git ان صورتوں کو خود بخود حل کر سکتا ہے جہاں ایک برانچ میں تبدیلیاں دوسری کی تبدیل شدہ جگہوں کو متاثر نہ کریں — چاہے دونوں فائلیں تبدیل کی گئی ہوں۔

مرج کے کام کرنے کی مثال

ایک منظر نامہ پر غور کریں: دو ڈیولپر ایک فیچر برانچ میں مختلف فائلوں پر کام کر رہے ہیں۔ پہلے نے LoginActivity.kt تبدیل کیا، دوسرے نے ProfileFragment.kt تبدیل کیا۔ جب وہ اپنی تبدیلیاں ضم کرتے ہیں، Git دیکھتا ہے کہ تبدیلیوں نے مختلف فائلوں کو متاثر کیا اور انسانی مداخلت کے بغیر خود بخود مرج انجام دیتا ہے۔

اگر دونوں ڈیولپر نے LoginActivity.kt تبدیل کیا، لیکن مختلف طریقوں میں — Git خود بخود بھی اسے سنبھال لے گا، تبدیلیوں کو سطر بہ سطر ضم کر کے۔ تنازع صرف اس وقت پیدا ہوتا ہے جب دونوں نے ایک ہی سطریں تبدیل کیں یا اگر ایک نے وہ کوڈ حذف کیا جو دوسرے نے تبدیل کیا۔

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

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

تنازع والے علاقوں کو خصوصی مارکرز سے نشان زد کیا جاتا ہے: <<<<<<< HEAD ہدف برانچ کا کوڈ دکھاتا ہے، ======= جدا کنندہ ہے، >>>>>>> source-branch ماخذ برانچ کا کوڈ دکھاتا ہے۔ ڈیولپر کو دستی طور پر انتخاب کرنا ہوتا ہے کہ کون سا ورژن رکھنا ہے یا انہیں یکجا کرنا ہے۔

# 1. مرج چلائیں اور تنازع دیکھیں
git merge feature/new-login
# آؤٹ پٹ: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. تنازعات والی فائلوں کی فہرست دیکھیں
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. تنازع حل کریں: فائل میں ترمیم کریں، مارکر ہٹائیں
# 4. حل شدہ فائل شامل کریں اور مرج مکمل کریں
git add src/ui/login/LoginActivity.kt
git merge --continue
# یا: git commit (--continue کے بغیر)

تنازعات حل کرنے کے لیے اوزار موجود ہیں: git mergetool ایک بصری انضمام کنندہ کھولتا ہے (Meld, Beyond Compare, VS Code)۔ بہت سے ڈیولپر IDE میں تنازعات حل کرنے کو ترجیح دیتے ہیں — IntelliJ IDEA اور Android Studio تین پینل کے موازنہ کے ساتھ ایک بلٹ ان ٹول فراہم کرتے ہیں جو اس عمل کو کافی آسان بناتا ہے۔

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

مرج بمقابلہ ریبیس: کب کیا چنیں

مرج اور ریبیس کے درمیان انتخاب Git میں سب سے عام تعمیراتی فیصلوں میں سے ایک ہے۔ دونوں طریقے تبدیلیوں کو یکجا کرتے ہیں، لیکن مختلف طریقے سے: مرج برانچنگ کی تاریخ کو محفوظ رکھتا ہے، ریبیس تاریخ کو دوبارہ لکھتا ہے اسے لکیری بناتا ہے۔

• مرج — سیاق و سباق کو محفوظ رکھتا ہے: دیکھ سکتے ہیں کہ کب اور کس برانچ سے انضمام کیا گیا۔ عوامی برانچوں (develop, main) اور ٹیم ورک کے لیے بہتر
• ریبیس — اضافی مرج کمٹ کے بغیر صاف لکیری تاریخ بناتا ہے۔ جائزے سے پہلے ذاتی فیچر برانچوں کے لیے بہتر
• قاعدہ: عوامی برانچیں جو دوسرے ڈیولپر استعمال کر رہے ہوں انہیں کبھی ریبیس نہ کریں

بہت سی ٹیمیں مخلوط طریقہ استعمال کرتی ہیں: فیچر برانچ کو develop کے ساتھ اپ ڈیٹ کرنے کے لیے ریبیس (git rebase develop)، پھر انضمام ریکارڈ کرنے کے لیے --no-ff پرچم کے ساتھ مرج۔ یہ فیچر کے اندر صاف تاریخ اور develop کی سطح پر معلوماتی انضمام پوائنٹس دیتا ہے۔