دمج (Merge) — ما هو، كيف يعمل merge واستراتيجيات الدمج

ما هو الدمج في Git

الدمج (Merge) هو أمر git merge الذي يجمع التغييرات من الفرع المحدد إلى الفرع الحالي. يجد Git السلف المشترك (commit الأساس)، ويحسب الفرق (diff) لكل فرع بالنسبة للسلف، وينشئ commit دمج يحتوي على مجموعة التغييرات المدمجة. النتيجة هي أن الفرع الهدف يتلقى جميع التغييرات من الفرع المدمج.

الصيغة: أثناء وجودك في الفرع الهدف (مثلاً main)، نفذ git merge feature. ينشئ Git تلقائيًا commit دمج إذا لم تكن هناك تعارضات. الرسالة الافتراضية لـ commit الدمج هي: «Merge branch 'feature' into main». يمكنك تغيير الرسالة باستخدام العلم -m أو تحريرها في المحرر المفتوح.

الدمج هو عملية غير مدمرة. على عكس rebase، لا يلمس الدمج الـ commits الموجودة: تبقى بنفس التجزئات (hashes) والمؤلفين والتواريخ. هذا يجعل الدمج الطريقة الوحيدة الآمنة لدمج الفروع التي يعمل عليها عدة مطورين في وقت واحد. إذا حدث خطأ ما، يمكن إلغاء الدمج باستخدام git merge --abort.

# التبديل إلى الفرع الهدف
git checkout main

# دمج فرع الميزة
git merge feature

# النتيجة — commit دمج مع أبوين اثنين
git log --oneline --graph

# دمج مع رسالة مخصصة
git merge feature -m "feat: integrate authentication module"

أنواع الدمج: regular وsquash وfast-forward

يدعم Git ثلاثة أوضاع للدمج يتم اختيارها حسب النتيجة المرغوبة. الدمج العادي (الافتراضي) ينشئ commit دمج. دمج squash يجمع كل commits فرع الميزة في commit واحد. Fast-forward يحرك مؤشر الفرع دون إنشاء commit، إذا أمكن. يعتمد اختيار الوضع على سير عمل الفريق وقواعد التاريخ.

الدمج العادي (--no-ff) — ينشئ commit دمج حتى لو كان يمكن تنفيذ الدمج كـ fast-forward. يوصى به للفرع main: commit الدمج يحدد بوضوح نقطة تكامل الميزة ويسمح بتراجع جميع تغييرات فرع الميزة بعملية revert واحدة لـ commit الدمج. يستخدم GitHub هذا الوضع افتراضيًا عند دمج PR عبر زر Merge.

دمج squash (--squash) — يجمع كل commits فرع الميزة في commit واحد في الفرع الهدف. مفيد عندما لا يجب أن يدخل التاريخ الأولي لفرع الميزة إلى main. العيب: فقدان الارتباط بالـ commits الأصلية — لا يمكن رؤية كيف تطورت الميزة خطوة بخطوة. يستخدم GitHub هذا الوضع عند اختيار «Squash and merge» في PR.

Fast-forward (--ff) — إذا لم يكن للفرع الهدف commits جديدة منذ تفرع فرع الميزة، يقوم Git ببساطة بتحريك المؤشر للأمام دون إنشاء commit دمج. يبقى التاريخ خطيًا. العلم --no-ff يفرض إنشاء commit دمج، بينما --ff-only سينتج خطأ إذا كان fast-forward غير ممكن.

# فرض commit دمج (موصى به لـ main)
git merge --no-ff feature

# Squash merge — كل الـ commits في واحد
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 — استراتيجية خاصة تتجاهل تمامًا التغييرات من الفرع المدمج وتحتفظ بالمحتوى الحالي للفرع الهدف. يتم إنشاء commit دمج، لكن المحتوى يبقى دون تغيير. مفيدة عندما تحتاج إلى تسجيل حقيقة الدمج في التاريخ ولكن في الواقع رفض جميع التغييرات من الفرع الآخر.

حل تعارضات الدمج

تعارض الدمج يحدث عندما يتم تغيير نفس الأسطر من ملف بطريقة مختلفة في كلا الفرعين. لا يمكن لـ 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

الدمج أفضل من rebase في عدة حالات رئيسية. الأولى: عند العمل مع فروع عامة يمكن للمطورين الآخرين الوصول إليها. الدمج لا يعيد كتابة التاريخ، لذلك يمكن للزملاء المزامنة بأمان. إجراء rebase على فرع عام ينشئ تاريخًا متباعدًا ويسبب تعارضات لكل من حصل بالفعل على الـ commits القديمة.

الحالة الثانية: عند إنهاء فرع ميزة. تفضل معظم الفرق الدمج (مع العلم --no-ff) في main لتسجيل لحظة تكامل الميزة. هذا يبسط التنقل في التاريخ ويسمح بتراجع ميزة كاملة بعملية git revert واحدة لـ commit الدمج. يوفر GitHub Flow افتراضيًا ثلاثة خيارات للدمج: الدمج البسيط ودمج squash ودمج rebase.

الحالة الثالثة: عند العمل مع pull request تمت مراجعته. يقدم GitHub وGitLab زر دمج بخيارات مختلفة. Merge (Create a merge commit) — تاريخ كامل مع commit دمج. Squash and merge — تاريخ نظيف بدون تفاصيل التطوير. Rebase and merge — تاريخ خطي بدون commit دمج، لكن مع إعادة كتابة الـ commits. يعتمد الاختيار على قواعد الفريق.

• الفروع العامة (main, develop) — دمج فقط، لا rebase أبدًا.
• إكمال PR — دمج مع --no-ff لتحديد نقطة التكامل.
• الفروع مع commits الآخرين — الدمج لا يعيد كتابة عمل الآخرين.
• قبل الإصدار — الدمج أكثر أمانًا لأنه أقل مخاطرة.
• فرع مشترك — إذا كان عدة مطورين يعملون على فرع، فإن الدمج إلزامي.

أفضل ممارسات دمج الفروع

القاعدة الأولى: كن دائمًا على أحدث إصدار من الفرع الهدف قبل الدمج. نفذ git checkout main && git pull قبل دمج فرع الميزة. هذا يقلل من التعارضات ويضمن أن commit الدمج يحتوي على جميع التغييرات الحديثة. إذا تقدم الفرع الهدف بشكل كبير، نفذ أولاً git merge main داخل فرع الميزة لحل التعارضات في سياقه.

القاعدة الثانية: اختبر الكود بعد الدمج. يمكن أن يغير الدمج السلوك حتى لو لم تكن هناك تعارضات. يجب أن يشغل خط أنابيب CI/CD الاختبارات على commit الدمج قبل الإرسال إلى الإنتاج. تستخدم بعض الفرق بوابات الدمج (merge gates) — فحوصات إلزامية تمنع الدمج حتى يتم اجتيازها.

القاعدة الثالثة: وثّق commits الدمج. الرسالة القياسية «Merge branch 'feature' into main» غير مفيدة كثيرًا. يوصى بإضافة وصف لما تم دمجه: «Merge authentication module: login, registration, password recovery». هذا يبسط تحليل التاريخ والبحث عن الانحدارات. في المشاريع الكبيرة، يتم إنشاء commits الدمج تلقائيًا من عنوان PR.

• الحداثة — قبل الدمج، تأكد من أن الفرع الهدف محدث (git pull).
• الاختبار — يجب أن يشغل CI/CD الاختبارات على commit الدمج الناتج.
• رسائل وصفية — حدد في commit الدمج أي ميزة تم دمجها.
• التكرار — ادمج فروع الميزات في أقرب وقت وكلما أمكن (أسبوع كحد أقصى).
• التراجع — git revert لـ commit الدمج يعيد الميزة بأكملها.