ما الفرق بين rebase و merge؟

Question

Accepted Answer

كل من **merge** و **rebase** يدمجان التغييرات من فرع إلى آخر، لكنهما يفعلان ذلك بطرق مختلفة: merge **يحافظ على السجل التاريخي** مع commit للدمج، بينما rebase **يعيد كتابة السجل التاريخي** لإنشاء تسلسل خطي. فهم الفرق ومتى تستخدم كل منهما مهم.

## Merge — يحافظ على السجل التاريخي (يجمع)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — يعيد الكتابة للحصول على سجل خطي (يعيد التشغيل)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **ينقل** commits الفرع الخاص بك لتبدأ من طرف فرع آخر، مما ينشئ commits جديدة — وينتج سجل تاريخي نظيف وخطي.

## القاعدة الذهبية للـ rebasing

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## متى تستخدم كل منهما

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## لماذا يهمك

فهم الفرق بين rebase و merge مهم لأن كلاهما يدمج التغييرات لكن بتأثيرات مختلفة بشكل أساسي على السجل التاريخي، واختيار الخيار الصحيح (والآمن) مهم، لذا فهو معرفة Git قيمة يتم مناقشتها أيضاً بشكل متكرر.

التمييز الأساسي — **merge يحافظ على السجل التاريخي** (ينشئ commit للدمج يسجل الفروع التي تم دمجها، مما يحافظ على السجل التاريخي الحقيقي للتطوير) بينما **rebase يعيد كتابة السجل التاريخي** (يعيد تشغيل commits على طرف فرع آخر لإنشاء تسلسل خطي نظيف كما لو تم العمل على أحدث الأكواد) — يؤثر على كيفية ظهور السجل التاريخي للمشروع وقراءته.

فهم المقارنات (merge: دقيق لكن قد يكون معقداً بـ merge commits؛ rebase: نظيف وخطي لكنه يعيد كتابة commits) يساعد في الاختيار بناءً على ما إذا كنت تقدر السجل التاريخي الحقيقي أو النظافة الخطية.

الأهم من ذلك، فهم **القاعدة الذهبية للـ rebasing** — **لا تقم أبداً بـ rebase للـ commits التي تم دفعها/مشاركتها** — أمر ضروري لأن rebase تعيد كتابة commits (تعطيها hashes جديدة)، لذا فإن rebase للسجل التاريخي المشترك ينحرف عما لديه المتعاونون، مما يسبب ارتباكاً وتعارضات خطيرة؛ rebase آمن فقط للـ commits المحلية غير المدفوعة.

قاعدة السلامة هذه حيوية وهي مصدر شائع للمشاكل عند انتهاكها.

فهم **متى تستخدم كل منهما** (merge لدمج الفروع المشتركة والحفاظ على السجل التاريخي، غالباً ما يكون الخيار الافتراضي للفريق لدمج الميزات عبر pull requests؛ rebase لتنظيف الـ commits المحلية قبل المشاركة أو الحفاظ على فرع الميزة محدثة خطياً — على الـ commits المحلية فقط) يعكس ممارسة Git سليمة.

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