دمج — ما هو، أنواع الدمج وآلية العمل

ما هو الدمج؟

الدمج — هو عملية أساسية في Git تجمع التغييرات من فرع (مصدر) إلى آخر (هدف). نتيجة للدمج، يتلقى الفرع الهدف جميع التزامات الفرع المصدر التي لم تكن فيه بعد. اعتماداً على الموقف، يمكن لـ Git تنفيذ الدمج بثلاث طرق مختلفة.

قيمة الدمج الرئيسية — الحفاظ على التاريخ: commit الدمج يسجل حقيقة دمج الفروع، ويحافظ على معلومات حول متى وأي الفروع تم دمجها. هذا يسهل تدقيق التغييرات، والبحث عن الانحدارات وفهم التسلسل الزمني للتطوير. في المشاريع الكبيرة، يعتبر commit الدمج الطريقة القياسية لتكامل الكود.

وفقاً GitLab Flow، يتم استخدام commits الدمج في 73% من الفرق العاملة مع Git. الأساليب البديلة (rebase، squash) تفضلها الفرق الموجهة نحو التاريخ الخطي. يعتمد اختيار الاستراتيجية على حجم الفريق، وتكرار الإصدارات والاتفاقيات المتبعة في المشروع.

متى يحدث الدمج

الدمج مطلوب عندما ينتهي المطور من العمل على ميزة ويريد دمجها في develop أو main. سيناريو نموذجي: أنشأ المطور فرع ميزة من develop، وعمل فيه لعدة أيام، وخلال ذلك الوقت ظهرت التزامات جديدة من أعضاء الفريق الآخرين في develop. قبل الدمج، يجب جمع التغييرات — ولهذا يستخدم الدمج.

بدون الدمج، من المستحيل العمل بشكل تعاوني على كود واحد في Git. في كل مرة يقوم فيها مطوران بإجراء تغييرات في وقت واحد على قاعدة كود واحدة، تتباعد فروعهما. الدمج هو الطريقة الوحيدة لجمع هذه التغييرات مرة أخرى دون فقدان البيانات.

أنواع الدمج في Git

يدعم Git ثلاثة أنواع من الدمج، كل منها مصمم لسيناريوه خاص به. يؤثر اختيار نوع الدمج على تاريخ الالتزامات، وسهولة التراجع، وقابلية قراءة السجل.

الدمج السريع

الدمج السريع يحدث عندما لا يحتوي الفرع الهدف على التزامات جديدة منذ إنشاء الفرع المصدر. في هذه الحالة، يقوم Git ببساطة بتحريك مؤشر الفرع الهدف للأمام إلى آخر commit للفرع المصدر. يبقى التاريخ خطياً، بدون commit دمج.

# Fast-forward merge: لم يتغير develop منذ إنشاء feature
git checkout develop
git merge feature/new-login

# النتيجة: مؤشر develop انتقل إلى نهاية feature
# لم يتم إنشاء أي merge commit

الدمج السريع مناسب للفروع قصيرة العمر حيث عمل المطور بمفرده. لكن لهذا النهج عيب: تُفقد المعلومات حول وجود الفرع — تبدو جميع الالتزامات وكأنها تمت مباشرة في develop.

الدمج ثلاثي الاتجاهات

الدمج ثلاثي الاتجاهات يتم تنفيذه عندما يكون لكلا الفرعين التزامات جديدة بعد نقطة التباعد. ينشئ Git commit دمج منفصل مع أصلين، يسجل حقيقة دمج الفروع. يوصى بهذا النهج لفروع الميزات في التطوير الجماعي.

# دمج ثلاثي الاتجاهات إجباري مع العلامة --no-ff
git checkout develop
git merge --no-ff feature/new-login

# تم إنشاء merge commit مع رسالة افتراضية
# يمكنك تعيين رسالتك الخاصة عبر -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

العلامة --no-ff تضمن إنشاء commit دمج، حتى لو كان الدمج السريع ممكناً. هذه أفضل ممارسة للحفاظ على معلومات التفرع في المشروع.

دمج الضغط

دمج الضغط يضغط جميع التزامات الفرع المصدر في واحد ويطبقه على الفرع الهدف. يُفقد تاريخ الميزة — commit واحد مع جميع التغييرات ينتهي في الفرع. هذا مناسب عندما لا تضيف الالتزامات التفصيلية في فرع الميزة قيمة للتاريخ العام.

# Squash merge: جميع التزامات feature مضغوطة في واحد
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

الضغط مناسب للمسودات، الفروع التجريبية والمواقف التي يكون فيها الحفاظ على تاريخ نظيف مهماً. الجانب السلبي — فقدان الارتباط بالالتزامات الأصلية، مما يعقد التراجع عن التغييرات الفردية.

استراتيجيات Ours و Theirs

Ours و Theirs — استراتيجيتان خاصتان للدمج في Git. Ours تتجاهل تماماً التغييرات من الفرع المصدر، تاركة فقط ما هو موجود في الفرع الهدف. Theirs، على العكس، تقبل نسخة الفرع المصدر في أي تعارض. هذه الاستراتيجيات مفيدة عند دمج كميات كبيرة من الكود عندما يكون معروفاً مسبقاً أي نسخة يجب أن تسود.

كيف يعمل الدمج

آلية الدمج في Git تعتمد على مقارنة ثلاث نقاط: السلف المشترك (merge base)، حالة الفرع المصدر وحالة الفرع الهدف. يجد Git merge base — آخر commit مشترك بين كلا الفرعين — ويحسب التغييرات التي حدثت في كل فرع بعد التباعد.

• الخطوة 1 — يحدد Git merge base: آخر commit موجود في كلا الفرعين
• الخطوة 2 — يبني Git فرقين: من merge base إلى source ومن merge base إلى target
• الخطوة 3 — يحاول Git تطبيق كلا مجموعتي التغييرات على merge base
• الخطوة 4 — إذا لم تتعارض التغييرات — يكتمل الدمج تلقائياً
• الخطوة 5 — إذا كان هناك تعارض — يتوقف Git ويطلب الحل

يستخدم Git خوارزمية دمج ثلاثية الاتجاهات تأخذ في الاعتبار ليس فقط نسختي الملف المقارنتين، ولكن أيضاً سلفهما المشترك. بفضل هذا، يمكن لـ Git حل المواقف تلقائياً حيث لا تؤثر التغييرات في فرع واحد على المناطق المعدلة في الآخر — حتى إذا تم تعديل كلا الملفين.

مثال على عمل الدمج

لنفكر في سيناريو: مطوران يعملان على ملفات مختلفة في فرع ميزة واحد. الأول غيّر LoginActivity.kt، والثاني غيّر ProfileFragment.kt. عندما يدمجان تغييراتهما، يرى Git أن التغييرات أثرت على ملفات مختلفة ويقوم بالدمج تلقائياً دون تدخل بشري.

إذا غيّر كلا المطورين LoginActivity.kt، ولكن في دوال مختلفة — سيتعامل 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 أداة مدمجة بمقارنة ثلاثية الألواح تبسط هذه العملية بشكل كبير.

نصائح لحل التعارضات: افهم دائماً ما يفعله كل جانب من التعارض، لا تحذف كود شخص آخر دون فهم منطقه، وإذا كان التعارض معقداً جداً — أشرك مؤلفي كلا الفرعين في الحل المشترك.

الدمج مقابل rebase: متى تختار ماذا

الاختيار بين الدمج و rebase — من أكثر القرارات المعمارية شيوعاً في Git. كلا النهجين يدمجان التغييرات، لكن يفعلان ذلك بشكل مختلف: الدمج يحافظ على تاريخ التفرع، rebase يعيد كتابة التاريخ مما يجعله خطياً.

• الدمج — يحافظ على السياق: يمكن رؤية متى ومن أي فرع تم الدمج. أفضل للفروع العامة (develop, main) والعمل الجماعي
• Rebase — ينشئ تاريخاً خطياً نظيفاً بدون commits دمج إضافية. أفضل لفروع الميزات الشخصية قبل المراجعة
• قاعدة: لا تقم أبداً بعمل rebase للفروع العامة التي يستخدمها مطورون آخرون

العديد من الفرق تستخدم نهجاً هجيناً: rebase لتحديث فرع الميزة مع develop (git rebase develop)، ثم دمج مع العلامة --no-ff لتسجيل الدمج. هذا يعطي تاريخاً نظيفاً داخل الميزة ونقاط دمج معلوماتية على مستوى develop.