Git on kenji.blog

【أوامر Git】الفرق بين rebase و merge، والاستخدام الصحيح في العمل الفعلي

Sun, 13 Sep 2026 09:00:00 +0900

1. مقدمة: لماذا يمثل الاختيار بين “merge و rebase” تحدياً مستمراً؟

Git هو نظام تحكم في الإصدارات لا غنى عنه في تطوير البرمجيات الحديثة. عندما يقوم العديد من المطورين بتعديل قاعدة الكود في وقت واحد، فإن نموذج الفروع القوي في Git يظهر فاعليته. ومع ذلك، في تطوير الفرق، يمثل النقاش حول “أيهما يجب استخدامه: merge أو rebase” موضوعاً يؤرق دائماً المطورين، من المبتدئين إلى الخبراء.

في هذا المقال، سنتعمق في الفروق بين آليات git merge و git rebase، من خلال استكشاف البنية الداخلية لـ Git، مثل الرسم البياني الموجه غير الدوري (DAG) والخصائص الرياضية لتجزئة الالتزام (Commit Hash). وبعد ذلك، سنشرح بالتفصيل كيفية التمييز بينهما في العمل الفعلي، مع تقديم أمثلة على سير العمل (Workflows). بدلاً من مجرد سرد الأوامر، فإن فهم العمليات الحسابية التي يقوم بها Git في الخلفية سيزيل الخوف من التعارضات (Conflicts)، مما يتيح لك بناء سجل تاريخي نظيف وقابل للتتبع.

2. البنية الداخلية لـ Git: تجزئة الالتزام ونموذج الكائنات

لفهم كيف يقوم Git بدمج السجل التاريخي، يجب أن نعرف أولاً كيف يخزن Git البيانات. لا يقوم Git فقط بحفظ اختلافات (Patches) تغييرات الملفات، بل يحتفظ بلقطة (Snapshot) لنظام الملفات بأكمله في نقطة زمنية معينة.

2.1 الخصائص التشفيرية لتجزئة الالتزام (Commit Hash)

يتم تعريف كل التزام (Commit) في Git بشكل فريد بواسطة سلسلة من 40 حرفاً سداسياً عشرياً (Hexadecimal)، يتم حسابها بناءً على محتواه باستخدام دالة التجزئة SHA-1 (Secure Hash Algorithm 1). يتكون كائن الالتزام من العناصر التالية:

مؤشر لكائن Tree: لقطة من هيكل الدليل والملفات (Blob) في تلك النقطة.
مؤشر للالتزام الأب (Parent Commit): قيمة تجزئة واحدة أو أكثر للالتزامات الآباء (الالتزام الأول لا يحتوي على أب، والتزام الدمج يحتوي على أبوين أو أكثر).
معلومات المؤلف (Author): الشخص الذي كتب الكود والوقت.
معلومات الملتزم (Committer): الشخص الذي أنشأ أو طبق الالتزام والوقت.
رسالة الالتزام (Commit Message): نص يوضح القصد من التغيير.

رياضياً، تُعرّف قيمة التجزئة $H(C)$ لكائن الالتزام $C$ على النحو التالي:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

هنا، تمثل $\parallel$ دمج (Concatenation) البيانات. نظراً لخصائص دالة التجزئة، فإن تغيير حرف واحد فقط في رسالة الالتزام، أو حتى وجود التزام أب مختلف، سيؤدي إلى إنشاء قيمة تجزئة مختلفة تماماً. وهذا يعني أن الالتزام غير قابل للتغيير (Immutable). عندما يقال إن rebase “يعيد كتابة السجل التاريخي”، فهذا يعني فعلياً أنه “ينشئ التزامات جديدة بمحتوى مشابه ولكن بقيم تجزئة مختلفة”.

حجم مساحة التجزئة هو $2^{160}$، ويمكن تقريب احتمال $P$ لحدوث تصادم (Collision) (أي أن يكون لالتزامين مختلفين نفس قيمة التجزئة) باستخدام نظرية مفارقة عيد الميلاد (Birthday Paradox) على النحو التالي (حيث $n$ هو عدد الالتزامات):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

هذا الاحتمال منخفض للغاية، وعملياً من شبه المستحيل أن تتصادم تجزئة التزامات Git.

3. نظرية الرسومات البيانية و DAG: النموذج الرياضي لسجل Git

يُنمذج السجل التاريخي لالتزامات Git على أنه “رسم بياني موجه غير دوري” (Directed Acyclic Graph, DAG) في نظرية الرسومات البيانية.

3.1 ما هو DAG (الرسم البياني الموجه غير الدوري)؟

في الرسم البياني $G = (V, E)$، تمثل $V$ مجموعة الالتزامات (العُقد - Vertices)، وتمثل $E$ مجموعة الحواف الموجهة (Directed Edges) التي تشير إلى علاقات الآباء والأبناء بين الالتزامات. في Git، يتجه اتجاه الحافة من “الالتزام الابن إلى الالتزام الأب”. هذا لأن الالتزام الجديد يحتفظ بمؤشر إلى الالتزام السابق.

graph BT
A["الالتزام A (الأولي)"]
B["الالتزام B"]
C["الالتزام C (الرئيسي)"]
D["الالتزام D (ميزة)"]
E["الالتزام E (دمج)"]
B --> A
C --> B
D --> B
E --> C
E --> D

أهم ميزة لـ DAG هي “عدم وجود دورات (Cycles)”. بفضل هذا، فإن الخوارزمية التي تتتبع السجل التاريخي للوراء لا تقع في حلقة مفرغة، وتصل بالتأكيد إلى النهاية (الالتزام الأولي).

3.2 الفرز الطوبولوجي وترتيب السجل

عند عرض السجل التاريخي باستخدام أوامر مثل git log، يتم ترتيب DAG كقائمة أحادية البعد بواسطة خوارزمية الفرز الطوبولوجي (Topological Sort). لأي حافة موجهة $u \to v$ في DAG (حيث $u$ هو ابن $v$)، يتم ترتيبها بحيث يظهر $u$ قبل $v$ في القائمة.

4. آليات git merge وأنواعها

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

4.1 دمج التقديم السريع (Fast-Forward) (–ff)

إذا كان الفرع الوجهة (مثال: main) هو السلف المباشر للفرع المصدر (مثال: feature)، يقوم Git بتنفيذ دمج “التقديم السريع (Fast-Forward)”. هذه العملية لا تُنشئ التزاماً جديداً، بل مجرد تحريك مؤشر الفرع للأمام.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

يحافظ دمج Fast-Forward على السجل التاريخي في خط مستقيم، ولكن من عيوبه فقدان السياق حول “أي مجموعة من الالتزامات تمثل تطوير ميزة (feature) واحدة”.

4.2 الدمج بدون التقديم السريع (Non-Fast-Forward) (–no-ff)

عند تحديد git merge --no-ff صراحةً، حتى وإن كان الموقف يسمح بـ Fast-Forward، يتم دائماً إنشاء “التزام دمج (Merge Commit)” جديد. التزام الدمج هو التزام خاص يمتلك أبوين.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "العمل الرئيسي 1"
merge feature type: NORMAL

ميزة هذه الطريقة هي أن وجود وتاريخ فرع الميزة يبقى بوضوح على DAG. عند حدوث مشكلة، يمكن التراجع بأمان عن الميزة بأكملها دفعة واحدة عن طريق تنفيذ git revert -m 1 <تجزئة التزام الدمج>.

4.3 خوارزمية الدمج ثلاثي الاتجاهات (3-Way Merge)

إذا كان لدى كل من الفرع الوجهة والفرع المصدر التزامات خاصة بهما، ينفذ Git دمجاً ثلاثي الاتجاهات. في هذه الحالة، يبحث Git في DAG للعثور على “أدنى سلف مشترك (Lowest Common Ancestor, LCA)” للفرعين.

التعقيد الزمني $T_{\text{LCA}}$ لخوارزمية العثور على LCA يمكن تنفيذه في وقت خطي بالنسبة لعدد العُقد $|V|$ وعدد الحواف $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

يقارن Git بين ثلاثة أشياء: “حالة LCA”، “حالة الفرع الحالي”، و"حالة الفرع الآخر"، وإذا لم تتعارض التغييرات، يقوم تلقائياً بإنشاء التزام دمج.

5. آلية git rebase وإعادة بناء السجل التاريخي

بينما يقوم git merge بـ “دمج” السجل، يقوم git rebase بـ “إعادة بناء (إعادة ربط)” السجل.

5.1 ما يحدث خلف كواليس Rebase

عندما تقوم بإعادة ربط (Rebase) فرع feature بفرع main (باستخدام git rebase main)، تكون العمليات الداخلية كما يلي:

إيجاد السلف المشترك (LCA) لفرعي feature و main.
حفظ الفروقات (Diffs) من LCA إلى طرف فرع feature في منطقة مؤقتة.
نقل مؤشر فرع feature إلى طرف فرع main.
تطبيق الفروقات المحفوظة تباعاً واحداً تلو الآخر (Cherry-Pick) فوق الأساس الجديد (طرف main)، وإنشاء التزامات جديدة.

graph TD
A["الالتزام A"] --> B["الالتزام B"]
B --> C["الالتزام C (الرئيسي)"]
B --> D["الالتزام D (الميزة القديمة)"]
D -.-> E["الالتزام 'D (الميزة الجديدة)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

النقطة المهمة هنا هي أن الالتزام $'D$ الناتج عن إعادة الربط له تجزئة مختلفة تماماً عن الالتزام الأصلي $D$، لأنه يمتلك التزاماً أباً مختلفاً (راجع تعريف دالة التجزئة $H(C)$ المذكور سابقاً).

5.2 إعادة الربط التفاعلية (Interactive Rebase)

يتيح لك استخدام git rebase -i (أو --interactive) التلاعب بالسجل التاريخي للالتزامات كما تشاء. إنها الأداة الأقوى لترتيب السجل المحلي.

pick: احتفاظ بالالتزام كما هو.
reword: تعديل رسالة الالتزام فقط.
edit: الإيقاف المؤقت لتعديل محتوى الالتزام.
squash: دمج هذا الالتزام مع الالتزام السابق ودمج الرسائل معاً.
fixup: مثل squash ولكن مع تجاهل رسالة هذا الالتزام.
drop: حذف الالتزام تماماً.

من الناحية الرياضية، إذا كان هناك $N$ من الالتزامات في فرع ما، فإن المتغيرات (التباديل) الممكنة $P$ للسجل الخطي التي يمكن إنشاؤها عن طريق تغيير ترتيب إعادة الربط هي كما يلي:

$$ P = N! $$

يمنح Git المطورين حرية اختيار من بين $N!$ طريقة، مما يتيح إبقاء السجل التاريخي منطقياً وجميلاً.

6. القاعدة الذهبية لإعادة الربط (The Golden Rule of Rebase)

بالرغم من قوة rebase الهائلة، إلا أن هناك قاعدة واحدة مطلقة.

“يجب ألا تقوم أبداً بإعادة ربط (Rebase) السجل التاريخي العام (Public History).” (Never rebase public history)

6.1 لماذا لا يجب إعادة ربط السجل العام؟

Git هو نظام لا مركزي. التزاماتك التي تم دفعها إلى origin/main تم استنساخها (Cloned) بالفعل في المستودعات المحلية للمطورين الآخرين. ماذا يحدث إذا قمت بإعادة ربط التزامات تم دفعها بالفعل، وأعدت كتابة السجل التاريخي، ثم قمت بالكتابة فوقه بالقوة باستخدام git push --force؟

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

القاعدة الذهبية هي إجراء إعادة الربط (Rebase) “فقط على الفروع المحلية التي لم تشاركها بعد مع أي شخص”.

7. حل التعارضات (Conflicts) و git rebase –continue

عندما يقوم عدة أشخاص بتعديل نفس الجزء من نفس الملف، يحدث تعارض (Conflict). تختلف عملية حل التعارضات بين merge و rebase.

7.1 حل التعارضات في Merge

في حالة git merge، يحدث حل التعارضات مرة واحدة فقط. قبل إنشاء التزام الدمج النهائي مباشرة، تقوم بتصحيح جميع أجزاء التعارض دفعة واحدة.

7.2 حل التعارضات في Rebase

في حالة git rebase، نظراً لطبيعته في إعادة تطبيق الالتزامات واحداً تلو الآخر، من الممكن حدوث تعارض في كل التزام.

عندما يحدث تعارض أثناء إعادة الربط، يقوم Git بإيقاف العملية مؤقتاً. تسلسل الحل هو كما يلي:

افتح محرر نصوص أو بيئة تطوير متكاملة (IDE مثل VS Code)، وقم بتصحيح علامات التعارض (<<<<<<< و ====== و >>>>>>>) يدوياً.
أضف الملفات المصححة إلى الفهرس (Index):
1

git add <الملف المعدل>
لا تقم بإنشاء التزام، بل استأنف عملية إعادة الربط:
1

git rebase --continue

إذا كنت ترغب في إلغاء عملية إعادة الربط نفسها والعودة إلى الحالة الأصلية، فقم بتنفيذ الأمر التالي:

1

git rebase --abort

(※ إذا لم تكن هناك حاجة لحل التعارض وأردت تخطي هذا الالتزام بالكامل، استخدم git rebase --skip)

8. الاستخدام الصحيح في العمل الفعلي (تطبيق سير العمل)

إذن، كيف يجب أن نميز بين استخدام merge و rebase في بيئة التطوير الفعلية؟ إليك النهج الأكثر قياسية وأماناً.

8.1 [السيناريو 1] ترتيب سجل العمل المحلي (استخدام Rebase)

لنفترض أنك تعمل على فرع ميزة (feature)، وتراكمت لديك الكثير من الالتزامات الصغيرة (مثل “تصحيح خطأ مطبعي” أو “حفظ مؤقت”). قبل فتح طلب سحب (Pull Request - PR)، استخدم إعادة الربط التفاعلية لترتيب هذه الالتزامات في وحدات ذات معنى.

1
2
3


# نفذ هذا أثناء تواجدك في فرع feature
git rebase -i HEAD~5
# (سيتم فتح المحرر، استخدم squash و fixup لتنظيف السجل)

بذلك، يمكنك إنشاء سجل التزامات جميل ومفهوم يسهل على المراجعين (Reviewers) فهم نواياك.

8.2 [السيناريو 2] مواكبة أحدث فرع main (استخدام Rebase)

إذا طالت فترة التطوير، واستمر دمج تغييرات الآخرين في فرع main، فإن فرع feature الخاص بك سيصبح قديماً. في هذه الحالة، قم بإعادة ربط فرع feature بأحدث main لمواكبته.

1
2
3
4
5


# الحصول على أحدث المعلومات لـ main
git fetch origin

# نقل فرع feature فوق أحدث main
git rebase origin/main

هذا يجعل السجل التاريخي مستقيماً، مما يمنع التعارضات عند الدمج لاحقاً. كما يمنع إنشاء التزامات دمج غير ضرورية (“Merge branch ‘main’ into feature”).

8.3 [السيناريو 3] دمج ميزة مكتملة (استخدام Merge)

اكتمل التطوير في فرع feature، وحان وقت دمجها في فرع main. هنا نستخدم git merge --no-ff (وهذا يعادل اختيار “Create a merge commit” في Pull Request على منصات مثل GitHub).

1
2
3


git checkout main
git merge --no-ff feature -m "دمج ميزة: تنفيذ ميزة تسجيل دخول المستخدم"
git push origin main

هذا يترك نقطة التقاء تاريخية (التزام دمج) على DAG لفرع main تفيد بأنه “هنا تم دمج ميزة واحدة”. عند مراجعة السجل لاحقاً، سيكون من الأسهل تتبع الكود حسب الميزة (Feature).

9. الخلاصة (ملخص)

في استخدام Git، إن الأساليب المتطرفة مثل “إنجاز كل شيء باستخدام Merge” أو “جعل كل شيء مستقيماً باستخدام Rebase” لها مزاياها وعيوبها.

أفضل ممارسة في العمل الفعلي هي النهج الهجين (Hybrid): “ترتيب السجل الخاص المحلي بشكل جميل باستخدام rebase، والاحتفاظ بسياق السجل العام المتكامل باستخدام merge –no-ff”.

محلياً (مساحة العمل الشخصية): استخدم rebase لإزالة الالتزامات غير الضرورية، ومواكبة أحدث خط رئيسي، والحفاظ على سجل خطي.
عالمياً (مساحة العمل المشتركة): استخدم merge --no-ff لتسجيل وجود فرع الميزة كالتزام دمج على DAG، مما يسهل عمليات التراجع (Revert) والتتبع.

من خلال فهم الخلفية المعمارية والرياضية مثل هيكل DAG وآليات دوال التجزئة، ترتقي أوامر Git من مجرد حفظ عن ظهر قلب إلى “تصميم مقصود للسجل التاريخي”. بالالتزام بالقاعدة الذهبية لإعادة الربط واختيار الأوامر المثلى وفقاً للموقف، يمكنك بناء سجل التزامات نظيف سهل القراءة والصيانة للفريق بأكمله.

أخطاء شائعة يقع فيها المبتدئون في Git وأوامر حلها (مثل حل النزاعات)

Sat, 12 Sep 2026 17:00:00 +0900

أخطاء شائعة يقع فيها المبتدئون في Git وأوامر حلها (مثل حل النزاعات)

1. مقدمة: لماذا نرتكب الأخطاء في Git؟

في تطوير البرمجيات، أصبح Git ضروريًا كالهواء والماء. ومع ذلك، بالنسبة للعديد من المبتدئين (وأحياناً حتى المحترفين)، يمكن أن يبدو Git كـ “صندوق سحري أسود مخيف”. تختفي الالتزامات (commits)، أو يتم دفع الكثير من التغييرات عن طريق الخطأ إلى الفرع الخاطئ، أو تمتلئ الشاشة برسائل أخطاء حول النزاعات (conflicts) لم تراها من قبل… عندما تقع في “فخاخ Git” هذه، يتوقف تقدم العمل تمامًا، وقد ينتابك الخوف من تدمير الكود المصدري في أسوأ الحالات.

لماذا يُعتبر Git بهذا الصعوبة ولماذا هو عرضة للتسبب في الأخطاء؟ السبب الأكبر هو “استخدام الأوامر السطحية عن طريق الحفظ دون فهم ما يحدث داخل Git”. يعتمد Git على فلسفة تصميم قوية كنظام للتحكم في الإصدارات الموزعة (DVCS)، لكن واجهته (CLI) ليست بديهية دائمًا.

في هذه المقالة، سنصنف العديد من “الأخطاء الشائعة” التي يواجهها مبتدئو Git في بيئة العمل إلى حالات، وسنقدم الأوامر المحددة لحل كل منها. ولكنها لن تكون مجرد قائمة أوامر (ورقة غش). سنتعمق بشكل مكثف بأكثر من 10,000 حرف لشرح “لماذا يحدث هذا الخطأ” و"كيف تتحرك البيانات داخل Git عند تنفيذ هذا الأمر"، مع شرح هيكل مجلد .git، والخلفية الرياضية لخوارزمية Diff التي تعمل خلف الكواليس، ورسومات توضيحية باستخدام Mermaid.

عندما تنتهي من قراءة هذه المقالة، يجب أن تتحرر من شعور “الخوف من Git”، وبدلاً من ذلك ستتأكد أنه “لا يوجد شريك موثوق به مثل Git”. والآن، لنتعمق في عالم Git العميق.

2. أعماق Git: فهم الهيكل الداخلي لمجلد `.git`

الخطوة الأولى لتسهيل استكشاف العديد من الأخطاء وإصلاحها هي معرفة كيف يقوم Git بتخزين البيانات. المجلد المخفي .git الموجود في الدليل الجذري لمشروعك هو قلب Git. لا يقوم Git بإدارة البيانات كمجرد تسجيل للاختلافات (patches) في الملفات بالتتابع، بل كـ تدفق من اللقطات (snapshots).

2.1 نموذج الكائنات: Blob، Tree، Commit

يستخدم Git بشكل رئيسي ثلاثة كائنات لتمثيل حالة المستودع. يتم تخزين هذه الكائنات في .git/objects.

Blob (Binary Large Object) كائن يخزن محتوى الملف نفسه. لا يتضمن اسم الملف أو معلومات الأذونات هنا. يتم ضغط سلسلة البايتات الصافية بواسطة zlib، ويتم التعرف عليها بواسطة قيمة تجزئة SHA-1 (رقم سداسي عشري من 40 حرفًا).
Tree كائن يمثل هيكل الدليل. يتضمن كائن Tree مؤشرات (قيم تجزئة SHA-1) لكائنات Tree أخرى (أدلة فرعية) وكائنات Blob (ملفات)، بالإضافة إلى أسماء الملفات وأذونات الوصول الخاصة بها. يلعب دورًا مشابهًا لدليل UNIX.
Commit يحتفظ بمؤشر لكائن Tree من المستوى الأعلى للمستودع بأكمله في نقطة زمنية معينة، وبيانات وصفية (المؤلف، تاريخ ووقت الالتزام، رسالة الالتزام)، ومؤشر للالتزام السابق (الالتزام الأصل).

graph TD
Commit1["الالتزام (تجزئة: 9f8a)"] --> Tree1["شجرة (تجزئة: 4b82)"]
Tree1 --> Blob1["كتلة (تجزئة: 8d7e) : index.js"]
Tree1 --> Tree2["شجرة (تجزئة: 3a2c) : src/"]
Tree2 --> Blob2["كتلة (تجزئة: 5f1b) : app.js"]

2.2 حقيقة HEAD والمراجع (Refs)

الكلمة HEAD التي تراها كثيرًا عند العمل مع Git. هي مرجع رمزي (Symbolic Reference) يشير إلى الفرع (أو الالتزام) الذي قمت بجلبه (checkout) حاليًا. إذا فتحت الملف .git/HEAD في محرر نصوص، فسترى سلسلة نصية مثل هذه.

1

ref: refs/heads/main

هذا يعني أن “الحالة الحالية هي عند نهاية الفرع main”. وإذا فتحت .git/refs/heads/main، ستجد قيمة تجزئة SHA-1 مكونة من 40 حرفًا مكتوبة هناك، وهذا يشير إلى أحدث كائن Commit. فرع Git هو ببساطة مؤشر خفيف (ملف) يشير إلى التزام معين. مجرد معرفة هذه الحقيقة يزيل الخوف من “هل سيتم حذف كل الملفات إذا قمت بحذف فرع؟”.

3. فهم Git من خلال الرياضيات: خوارزمية Diff ودالة التجزئة

عندما يكتشف Git تعارضًا أو يعرض الاختلافات بين الملفات، تعمل خوارزميات متقدمة داخليًا.

3.1 خوارزمية Diff لمايرز

خوارزمية الكشف عن الفروق الافتراضية في Git هي خوارزمية ابتكرها Eugene W. Myers. عندما يكون لدينا ملفان نصيان $A$ و $B$، فإن مسألة العثور على “الحد الأدنى من خطوات التحرير (الإدراج والحذف)” لتحويل $A$ إلى $B$ يمكن نمذجتها كمسألة أقصر مسار في نظرية الرسوم البيانية.

لنفترض أن طولي السلسلتين هما $N, M$ على التوالي، والمجموع هو $V = N + M$. في خوارزمية مايرز، نبحث عن مسافة التحرير (Edit Distance) $D$. يتم التعبير عن التعقيد الزمني لهذه الخوارزمية بالمعادلة التالية:

$$ \mathcal{O}(V \cdot D) $$

هنا، إذا كان الاختلاف بين الملفات صغيرًا (أي أن $D$ صغير)، فإن الخوارزمية تعمل بسرعة عالية جدًا $\mathcal{O}(V)$. ومع ذلك، إذا كانت الملفات مختلفة تمامًا، تصبح $D \approx V$، ويكون التعقيد في أسوأ الحالات هو $\mathcal{O}(V^2)$.

3.2 Patience Diff و Histogram Diff

على الرغم من أن خوارزمية مايرز ممتازة، إلا أنها قد تولد اختلافات ليست بديهية (لا معنى لها) للبشر عند إعادة ترتيب تسلسل الدوال أو الفئات بشكل كبير. لحل هذه المشكلة، قام Git بتطبيق Patience Diff و Histogram Diff.

يركز Patience Diff على “الأسطر الفريدة التي تظهر مرة واحدة فقط في كلا الملفين”، ويجد أطول تسلسل فرعي مشترك (LCS) بينها. إذا كان عدد العناصر الفريدة هو $U$، يمكن حساب LCS بالتعقيد التالي:

$$ \mathcal{O}(U \log U) $$

إذا شعرت بصعوبة في حل النزاعات، فإن إحدى الطرق هي استخدام git diff --histogram أو تحديد هذه الخوارزمية في استراتيجية الدمج (git merge -s recursive -X histogram).

3.3 SHA-1 واحتمال التصادم

يدير Git جميع الكائنات باستخدام قيم تجزئة SHA-1. حجم فضاء التجزئة هو $2^{160}$. عند تقريب احتمال تصادم التجزئة (حيث يكون للمحتوى المختلف نفس قيمة التجزئة) باستخدام مفارقة يوم الميلاد (Birthday Paradox)، فإن عدد الكائنات $k$ المطلوب للوصول إلى احتمال تصادم $p$ بنسبة 50٪ هو كالتالي:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

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

4. دراسة حالة 1: قمت بالالتزام في فرع خاطئ!

[الموقف] دون أن تدرك أنك تعمل في فرع main، كتبت الكود للميزة الجديدة بحماس، وقمت بتنفيذ git commit. كان يجب أن تنشئ فرعًا باسم feature/login وتعمل هناك!

الحل: `git reset` وإنشاء فرع

في Git، الالتزام هو كائن مستقل، والفرع مجرد مؤشر. لذلك، يمكن حله فورًا من خلال عملية “إنشاء فرع جديد ثم إرجاع مؤشر الفرع الحالي”.

1
2
3
4
5
6
7
8
9


# 1. إنشاء فرع جديد يشير إلى الالتزام الحالي (الالتزام الذي قمت به عن طريق الخطأ)
$ git branch feature/login

# 2. إرجاع مؤشر فرع main إلى الالتزام السابق (HEAD~1)
# يسمح لك --keep بإعادة التعيين بأمان مع الاحتفاظ بالتغييرات غير الملتزم بها في دليل العمل.
$ git reset --keep HEAD~1

# 3. التبديل إلى الفرع الصحيح
$ git checkout feature/login

التوضيح بالرسم: ماذا حدث بالداخل؟

دعونا نتصور حركة مؤشرات الفروع في هذه المرحلة باستخدام gitGraph في Mermaid.

gitGraph
commit id: "الالتزام الأولي"
commit id: "إصلاح خطأ"
commit id: "التزام خاطئ" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

في البداية، كان كل من main و HEAD يشيران إلى “التزام خاطئ”، ولكن باستخدام git branch feature/login، يتم إنشاء مؤشر جديد هناك. بعد ذلك، عن طريق git reset، يعود مؤشر main فقط إلى موضع “إصلاح خطأ”. لم يتم حذف الكائنات نفسها على الإطلاق.

5. دراسة حالة 2: أريد التراجع عن التزام تم دفعه بالفعل!

[الموقف] في منتصف الليل، قمت بالالتزام بكود مليء بالأخطاء، ودفعته إلى المستودع البعيد باستخدام git push origin main. أدركت أن هناك خطأً فادحًا وشعرت بالذعر.

الحل 1: إبطال التاريخ باستخدام `git revert` (موصى به وآمن)

في تطوير الفريق، يُحظر تمامًا التلاعب بسجل الالتزامات التي تم دفعها بالفعل باستخدام git reset وما شابه. لأن ذلك سيتعارض مع المستودعات المحلية للمطورين الآخرين. النهج الصحيح هو “إنشاء التزام جديد عكسي يلغي تمامًا التغييرات في الالتزام الخاطئ”. هذا هو git revert.

1
2
3
4
5
6
7


# إنشاء التزام يلغي أحدث التزام
$ git revert HEAD
[main 7f3a8b2] Revert "رسالة الالتزام الخاطئ"
 1 file changed, 1 insertion(+), 10 deletions(-)

# الدفع إلى المستودع البعيد
$ git push origin main

gitGraph
commit id: "الالتزام أ"
commit id: "الالتزام ب (خطأ)"
commit id: "تراجع عن الالتزام ب" type: REVERSE

يستمر التاريخ في التقدم، وحالة الكود فقط هي التي تعود إلى ما كانت عليه.

الحل 2: التلاعب بالتاريخ باستخدام `git push --force-with-lease`

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

1
2
3
4
5
6
7


# إعادة التعيين محليًا وتصحيح الالتزام
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# الكتابة فوق التاريخ البعيد إجباريا
$ git push origin feature/login --force-with-lease

--force-with-lease هو دفع إجباري آمن لمنع حوادث الكتابة فوق عمل الآخرين عن طريق الخطأ.

6. دراسة حالة 3: أريد التبديل إلى فرع آخر في منتصف العمل (سحر Stash)

[الموقف] أثناء تنفيذ ميزة جديدة في الفرع feature/A، كان الكود المصدري في حالة غير مكتملة ولم يتم تجميعه بعد (compile). فجأة، يطلب منك مديرك إصلاح خلل طارئ في بيئة الإنتاج على الفرع main فورًا!

الحل: الإخفاء باستخدام `git stash`

git stash هو أمر يقوم بإخفاء التغييرات غير الملتزم بها مؤقتًا في منطقة التخزين المؤقت.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. إخفاء التغييرات قيد التقدم
$ git stash push -m "WIP: feature A partially implemented"

# 2. السماح بالتبديل إلى فرع main
$ git checkout main
# ... (تنفيذ عمل إصلاح الخلل الطارئ، الالتزام، والدفع) ...

# 3. العودة إلى الفرع الأصلي بعد الانتهاء من العمل
$ git checkout feature/A

# 4. استعادة التغييرات المخفاة
$ git stash pop

عند تنفيذ git stash، يقوم Git بإنشاء كائني Commit خاصين داخليًا ويحفظهما في مرجع يسمى refs/stash. بمعنى آخر، الاستخفاء (Stash) هو في النهاية “التزام مؤقت بلا اسم”.

7. دراسة حالة 4: حالة “الرأس المنفصل” (Detached HEAD) المرعبة

[الموقف] أردت التحقق من الكود في نقطة زمنية معينة في الماضي فنفذت git checkout 9f8a7b6. فظهرت رسالة You are in 'detached HEAD' state.. قمت بالالتزام على هذه الحالة، لكن عندما قمت بالتبديل إلى فرع آخر اختفى الالتزام!

آلية الرأس المنفصل (Detached HEAD)

عادةً يشير HEAD إلى فرع مثل refs/heads/main. ومع ذلك، عند جلب (checkout) التزام معين مباشرةً، سيشير HEAD مباشرة إلى كائن الالتزام. يسمى هذا الرأس المنفصل (Detached HEAD).

graph TD
A["الالتزام أ"] --> B["الالتزام ب"]
B --> C["الالتزام ج"]
C --> D["الالتزام د"]
BranchMain["فرع: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

حتى لو قمت بالالتزام مرارًا وتكرارًا في هذه الحالة، فلن يقوم أي فرع بتتبع هذا الالتزام الجديد. بمجرد التبديل إلى فرع آخر، سيضيع الالتزام الجديد.

الحل: حفظه كفرع جديد

يمكن حل ذلك عن طريق إنشاء فرع جديد في مكانك الحالي.

1
2


# أنشئ فرعًا جديدًا في موقع HEAD الحالي وبدّل إليه
$ git checkout -b feature/recovered-work

8. دراسة حالة 5: حل النزاعات أثناء الدمج وإعادة التعيين

[الموقف] عندما نفذت git merge أو git rebase، ظهرت رسالة CONFLICT (content) وتم إيقاف العملية.

الفرق بين الدمج (Merge) وإعادة التعيين (Rebase)

الدمج (Merge) يقوم بدمج ثلاثي (3-way merge) باستخدام أحدث الالتزامات لفرعين مع الجد المشترك، وينشئ التزام دمج (merge commit).
إعادة التعيين (Rebase) يحفظ التزامات الفرع الحالي مؤقتًا ويطبقها مرة أخرى على رأس الهدف. يصبح التاريخ خطًا مستقيمًا.

gitGraph
commit id: "م1"
commit id: "م2"
branch feature
checkout feature
commit id: "ف1"
commit id: "ف2"
checkout main
commit id: "م3"
merge feature

كيفية حل النزاعات

يتم إدراج العلامات التالية في الملف الذي حدث فيه النزاع.

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

إجراءات الحل بسيطة للغاية.

حذف العلامات وتصحيح الكود ليكون بالشكل الصحيح.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

إضافة الملف الذي تم حله إلى منطقة التجهيز (staging). أمر git add له دور “إخبار Git بأن النزاع قد تم حله”.
1

$ git add index.js

إكمال العملية.

1
2
3
4
5


# في حالة الدمج
$ git commit -m "Resolve merge conflict in index.js"

# في حالة إعادة التعيين
$ git rebase --continue

إذا شعرت بالذعر، يمكنك إلغاء العملية في أي وقت باستخدام $ git merge --abort أو $ git rebase --abort.

9. دراسة حالة 6: سجل الالتزامات فوضوي! `git rebase -i`

[الموقف] حدثت الكثير من الالتزامات الصغيرة مثل “إصلاح خطأ مطبعي”، “تعديل إضافي”، “إضافة اختبار”. إذا قمت بالدمج إلى main هكذا، سيكون السجل فوضويًا.

الحل: إعادة التعيين التفاعلي

باستخدام git rebase -i (تفاعلي)، يمكنك تغيير ترتيب الالتزامات السابقة، أو دمج التزامات متعددة في واحد (squash)، أو تعديل رسالة الالتزام.

1
2


# تنظيم آخر 3 التزامات
$ git rebase -i HEAD~3

يفتح المحرر ويتم عرض ما يلي.

1
2
3


pick 1a2b3c4 إصلاح خطأ مطبعي
pick 2b3c4d5 تعديل إضافي
pick 3c4d5e6 إضافة اختبار

أعد كتابتها كالتالي.

1
2
3


pick 1a2b3c4 تنفيذ الميزة X
squash 2b3c4d5 تعديل إضافي
squash 3c4d5e6 إضافة اختبار

عندما تحفظ وتغلق، ستندمج هذه الالتزامات الثلاثة بشكل جميل في التزام واحد.

10. دراسة حالة 7: لا أعرف متى حدث الخطأ! `git bisect`

[الموقف] الفرع الحالي main يحتوي على خلل، لكن عند الإصدار قبل شهر كان يعمل بشكل جيد. أريد تحديد الالتزام الذي أدخل الخلل، ولكن هناك أكثر من 100 التزام ومن المستحيل القيام بذلك يدويًا!

الحل: تحديد الخلل باستخدام البحث الثنائي

يحتوي Git على أداة مدمجة للعثور على الالتزام الذي يحتوي على الخلل باستخدام البحث الثنائي (Binary Search) الرياضي. التعقيد هو $\mathcal{O}(\log N)$، لذلك حتى لو كان هناك 1000 التزام، يمكن تحديد الخلل بحوالي 10 اختبارات.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# بدء البحث
$ git bisect start

# الالتزام الحالي يحتوي على خلل (bad)
$ git bisect bad

# قبل شهر (على سبيل المثال التجزئة a1b2c3d) كان جيدًا (good)
$ git bisect good a1b2c3d

# سيقوم Git تلقائيًا بجلب التزام وسيط، لذا قم بتشغيل الاختبار
# إذا نجح الاختبار:
$ git bisect good
# إذا فشل الاختبار:
$ git bisect bad

بتكرار ذلك، سيخبرك Git بدقة “هذا هو أول التزام سيء”. عند الانتهاء، ارجع إلى الحالة الأصلية باستخدام $ git bisect reset.

11. شبكة الأمان القصوى: `git reflog`

السر النهائي لأي “خطأ” في Git هو git reflog. يسجل Git جميع عملياتك المحلية (تاريخ حركة HEAD) لفترة معينة. حتى إذا قمت بحذف فرع أو إعادة تعيين خاطئة، يمكنك العثور على التجزئة السابقة باستخدام git reflog، واستردادها ببساطة عن طريق استخدام git reset --hard إلى تلك النقطة.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. الخاتمة

لقد شرحنا بالتفصيل الأخطاء التي يسهل على مبتدئي Git الوقوع فيها، والآليات الكامنة وراءها في Git، وكيفية حلها. الالتزام في الفرع الخطأ، التراجع عن الالتزامات المدفوعة، استخدام Stash، النجاة من Detached HEAD، وحل النزاعات. المهم في كل هذا هو “تخيل كيف يتلاعب Git بالكائنات والمؤشرات خلف الكواليس”.

تُحسب الفروق بين الملفات بخوارزمية Diff صارمة يمكن التعبير عنها رياضيًا، وتُضمن سلامة التاريخ بواسطة دوال التجزئة المشفرة. إذا فهمت فلسفة التصميم الجميلة هذه، ستدرك أن Git ليس أبدًا “صندوقًا أسود غامضًا”، بل هو أقوى درع يحمي كود المصدر الخاص بك بقوة.

في المرة القادمة التي تعتقد فيها “لقد أفسدت الأمر!"، لا تقم بإغلاق الطرفية (terminal) في حالة من الذعر، بل خذ نفسًا عميقًا واكتب git status. سيقدم لك Git بالتأكيد تلميحات لاستعادة عملك.

Git on kenji.blog

【أوامر Git】الفرق بين rebase و merge، والاستخدام الصحيح في العمل الفعلي

1. مقدمة: لماذا يمثل الاختيار بين “merge و rebase” تحدياً مستمراً؟

2. البنية الداخلية لـ Git: تجزئة الالتزام ونموذج الكائنات

2.1 الخصائص التشفيرية لتجزئة الالتزام (Commit Hash)

3. نظرية الرسومات البيانية و DAG: النموذج الرياضي لسجل Git

3.1 ما هو DAG (الرسم البياني الموجه غير الدوري)؟

3.2 الفرز الطوبولوجي وترتيب السجل

4. آليات git merge وأنواعها

4.1 دمج التقديم السريع (Fast-Forward) (–ff)

4.2 الدمج بدون التقديم السريع (Non-Fast-Forward) (–no-ff)

4.3 خوارزمية الدمج ثلاثي الاتجاهات (3-Way Merge)

5. آلية git rebase وإعادة بناء السجل التاريخي

5.1 ما يحدث خلف كواليس Rebase

5.2 إعادة الربط التفاعلية (Interactive Rebase)

6. القاعدة الذهبية لإعادة الربط (The Golden Rule of Rebase)

6.1 لماذا لا يجب إعادة ربط السجل العام؟

7. حل التعارضات (Conflicts) و git rebase –continue

7.1 حل التعارضات في Merge

7.2 حل التعارضات في Rebase

8. الاستخدام الصحيح في العمل الفعلي (تطبيق سير العمل)

8.1 [السيناريو 1] ترتيب سجل العمل المحلي (استخدام Rebase)

8.2 [السيناريو 2] مواكبة أحدث فرع main (استخدام Rebase)

8.3 [السيناريو 3] دمج ميزة مكتملة (استخدام Merge)

9. الخلاصة (ملخص)

أخطاء شائعة يقع فيها المبتدئون في Git وأوامر حلها (مثل حل النزاعات)

أخطاء شائعة يقع فيها المبتدئون في Git وأوامر حلها (مثل حل النزاعات)

1. مقدمة: لماذا نرتكب الأخطاء في Git؟

2. أعماق Git: فهم الهيكل الداخلي لمجلد .git

2.1 نموذج الكائنات: Blob، Tree، Commit

2.2 حقيقة HEAD والمراجع (Refs)

3. فهم Git من خلال الرياضيات: خوارزمية Diff ودالة التجزئة

3.1 خوارزمية Diff لمايرز

3.2 Patience Diff و Histogram Diff

3.3 SHA-1 واحتمال التصادم

4. دراسة حالة 1: قمت بالالتزام في فرع خاطئ!

الحل: git reset وإنشاء فرع

التوضيح بالرسم: ماذا حدث بالداخل؟

5. دراسة حالة 2: أريد التراجع عن التزام تم دفعه بالفعل!

الحل 1: إبطال التاريخ باستخدام git revert (موصى به وآمن)

الحل 2: التلاعب بالتاريخ باستخدام git push --force-with-lease

6. دراسة حالة 3: أريد التبديل إلى فرع آخر في منتصف العمل (سحر Stash)

الحل: الإخفاء باستخدام git stash

7. دراسة حالة 4: حالة “الرأس المنفصل” (Detached HEAD) المرعبة

آلية الرأس المنفصل (Detached HEAD)

الحل: حفظه كفرع جديد

8. دراسة حالة 5: حل النزاعات أثناء الدمج وإعادة التعيين

الفرق بين الدمج (Merge) وإعادة التعيين (Rebase)

كيفية حل النزاعات

9. دراسة حالة 6: سجل الالتزامات فوضوي! git rebase -i

الحل: إعادة التعيين التفاعلي

10. دراسة حالة 7: لا أعرف متى حدث الخطأ! git bisect

الحل: تحديد الخلل باستخدام البحث الثنائي

11. شبكة الأمان القصوى: git reflog

12. الخاتمة

2. أعماق Git: فهم الهيكل الداخلي لمجلد `.git`

الحل: `git reset` وإنشاء فرع

الحل 1: إبطال التاريخ باستخدام `git revert` (موصى به وآمن)

الحل 2: التلاعب بالتاريخ باستخدام `git push --force-with-lease`

الحل: الإخفاء باستخدام `git stash`

9. دراسة حالة 6: سجل الالتزامات فوضوي! `git rebase -i`

10. دراسة حالة 7: لا أعرف متى حدث الخطأ! `git bisect`

11. شبكة الأمان القصوى: `git reflog`