لديك فرع footer مكتمل، وفرع main لا يحتويه بعد. الدمج (merge) هو الطريقة التي ينضمّ بها العمل على خط من السجلّ إلى خط آخر. لدى Git طريقتان لفعل ذلك، والطريقة التي تحدث ليست عشوائية: تستطيع توقّعها بالنظر إلى الرسم البياني قبل أن تكتب أي شيء.
أولًا، القاعدة التي تجنّبك أكبر قدر من الارتباك: أنت تدمج فرعًا آخر في الفرع الذي أنت عليه. الأمر git merge footer يعني «أدخِل عمل footer إلى فرعي الحالي». لا يتحرّك إلا الفرع الحالي. أما الفرع الذي سمّيته فيبقى تمامًا حيث كان.
إذن الروتين دائمًا: انتقل إلى الفرع الذي يجب أن يستقبل العمل، ثم ادمج.
\ngit switch main\ngit merge footerمنذ أنشأت footer، لم ينشئ أحد أي commit على main. كل commit على main موجود أصلًا في سجلّ footer. لا يحتاج Git إلى جمع أي شيء؛ إنه ينزلق بـ main إلى الأمام حتى آخر commit في footer:
Updating c39be11..f1a3b07\nFast-forward\n index.html | 8 ++++++++\n styles.css | 12 ++++++++++++\n 2 files changed, 20 insertions(+)هذا هو الـ fast-forward (التقديم السريع): لا commit جديد، بل مؤشّر يتحرّك على commits موجودة. ويبقى السجلّ خطًا مستقيمًا، كأنك عملت على main طوال الوقت.
والآن الحالة الأكثر إثارة. بينما كنت تبني dark-mode، صحّحت أيضًا خطأً إملائيًا مباشرة على main. في كل فرع commits يفتقدها الآخر؛ لقد تباعدا (diverged). لا يوجد خط مستقيم يمكن الانزلاق عليه.
ينفّذ Git دمجًا ثلاثيًا (three-way merge). يجد الـ merge base، وهو أحدث commit يتشاركه الفرعان، ويقارن طرف كل فرع به. التغيير الذي جرى على طرف واحد فقط يُؤخذ. والتغييرات التي جرت على الطرفين في مواضع مختلفة تُؤخذ كلها. أما إن غيّر الطرفان الأسطر نفسها، فيتوقّف Git ويسألك؛ هذا هو التعارض (conflict)، وله الدرس التالي كاملًا.
\ngit switch main\ngit merge dark-modeيفتح Git محرّرك بالرسالة Merge branch 'dark-mode'. احفظ وأغلق، وسترى:
Merge made by the 'ort' strategy.\n styles.css | 24 ++++++++++++++++++++++++\n 1 file changed, 24 insertions(+)ort هو اسم خوارزمية الدمج الافتراضية في Git؛ ولا تحتاج إلى اختيارها. والنتيجة merge commit: commit له أبوان، طرف main السابق وطرف dark-mode. ولقطته تحتوي خطَّي العمل كليهما.
النتيجتان تحتويان الملفات النهائية نفسها. الاختلاف في طريقة قراءة السجلّ، وللفرق آراء في ذلك.
\nخياران يسمحان لك بالاختيار بدل ترك الرسم يقرّر:
\ngit merge --no-ff footer # always create a merge commit, even if fast-forward is possible\ngit merge --ff-only footer # fast-forward or refuse; never create a merge commitخياري الافتراضي لموقع شخصي يعمل عليه شخص واحد: دع Git ينفّذ fast-forward للفروع الصغيرة، ولا ترهق نفسك بالتفكير في الأمر. أما في الفريق، فاتبع عُرف الفريق، وهو عادةً يُضبط على GitHub ولا يُكتب يدويًا. والأهمّ من السياسة بكثير أن يحمل كل فرع قطعة عمل واحدة متماسكة، فأيًّا كان الشكل الذي يتّخذه السجلّ، تكون كل خطوة فيه مفهومة.
\n--ff-only عادة أمان جيدة حين لا تتوقّع إلا اللحاق بالتحديثات، مثلًا عند تحديث main المحلي. إن رفض Git، فهذا خبر بحدّ ذاته: شيء ما تباعد دون علمك. وعلى GitHub ستقابل الاختيار نفسه في صورة طرق الدمج (merge methods) في الـ pull request في القسم الثالث.
تستطيع فحص الـ merge base بنفسك قبل الدمج، وهذا يخبرك كم ابتعد الفرعان:
\ngit merge-base main dark-mode\ngit log --oneline main..dark-mode # commits on dark-mode that main lacks\ngit log --oneline dark-mode..main # and the reverseإن كان ناتج أمر الـ log الثاني فارغًا، فـ main لم يتحرّك وسيكون الدمج fast-forward.
بعد دمج footer، يكون اسم الفرع قد أدّى مهمّته. احذفه:
git branch -d footerينجح -d لأن الـ commits قابلة للوصول من main. الـ commits نفسها تبقى في السجلّ إلى الأبد؛ والذي يذهب هو الورقة اللاصقة فقط. نظّف الفروع المدموجة أولًا بأول، فيبقى ناتج git branch قائمة قصيرة بالعمل الجاري فعلًا.
حتى الآن مرّ كل دمج بسلاسة لأن الفرعين لمسا أسطرًا مختلفة. في الدرس التالي ستجعلهما يتصادمان عن قصد، وتحلّ التعارض خطوة بخطوة.
\n","toc":[{"id":"sec-1","text":"قاعدة الاتجاه","level":2},{"id":"sec-2","text":"الحالة الأولى: fast-forward","level":2},{"id":"sec-3","text":"الحالة الثانية: دمج حقيقي","level":2},{"id":"sec-4","text":"الاختيار عن قصد","level":2},{"id":"sec-5","text":"بعد الدمج","level":2}],"takeaways":["أنت تدمج دائمًا فرعًا آخر في الفرع الذي أنت عليه؛ ولا يتحرّك إلا الفرع الحالي.","إن لم يتحرّك الفرع الحالي منذ بدأ الفرع الآخر، يقدّم Git المؤشّر إلى الأمام (fast-forward) ولا ينشئ commit جديدًا.","إن كان في الفرعين commits جديدة، ينفّذ Git دمجًا ثلاثيًا (three-way merge) انطلاقًا من سلفهما المشترك، ويسجّل merge commit له أبوان.","--no-ff يفرض إنشاء merge commit ليُبقي الـ feature مجمّعة؛ و --ff-only يرفض أي شيء غير الـ fast-forward."],"further":[{"title":"Basic Branching and Merging (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging"},{"title":"git merge reference","url":"https://git-scm.com/docs/git-merge"},{"title":"git merge-base reference","url":"https://git-scm.com/docs/git-merge-base"}],"quiz":[{"q":"أنت على main. منذ أنشأت footer منه، لم يكسب main أي commit، بينما كسب footer ثلاثة. ماذا يفعل git merge footer؟
main إلى آخر commit في footer دون إنشاء commit جديد.","why":"صحيح. main سلف لـ footer، لذا يستطيع Git تقديم المؤشّر (fast-forward). ويبقى السجلّ خطًا مستقيمًا."},{"text":"ينشئ merge commit له أبوان.","why":"هذا يحدث فقط حين يتحرّك الفرعان كلاهما، أو حين تطلبه صراحة بـ --no-ff."},{"text":"ينسخ الـ commits الثلاثة إلى main بمعرّفات جديدة.","why":"هذا وصف لعملية rebase أو cherry-pick. أما الـ merge فيعيد استخدام الـ commits الموجودة."},{"text":"يُرجع footer إلى حيث يقف main.","why":"الـ merge لا يحرّك أبدًا الفرع الذي تسمّيه، بل الفرع الذي أنت عليه فقط."}],"answer":0},{"q":"كنت تقصد إدخال dark-mode إلى main، لكنك كنت على dark-mode وشغّلت git merge main. ما الذي حدث؟
main في فرع feature.","why":"يمكن ذلك، والفرق تفعله لتحديث فرع طويل العمر. إنه مسموح، لكنه ليس ما أردته هنا."},{"text":"صار main يحتوي عمل الوضع الداكن.","why":"main لم يتحرّك. وحده الفرع الذي أنت عليه، dark-mode، يمكن أن يتغيّر أثناء الدمج."},{"text":"كسب dark-mode الـ commits الجديدة من main؛ و main لم يتغيّر.","why":"صحيح. انتقل إلى main بـ git switch main وشغّل git merge dark-mode لتدمج في الاتجاه الذي قصدته."}],"answer":3},{"q":"أيّ commit يستخدمه Git نقطة انطلاق حين ينفّذ دمجًا ثلاثيًا لـ dark-mode في main؟
يريد فريقك أن تظهر كل feature في سجلّ main على شكل merge commit واحد، حتى حين يكون الـ fast-forward ممكنًا. أيّ خيار يحقّق ذلك؟
git merge --ff-only feature","why":"هذه هي السياسة المعاكسة. إنها تسمح بالـ fast-forward فقط وترفض إنشاء merge commits."},{"text":"git merge --squash feature","why":"هذا يجهّز التغييرات المجمّعة دون إنشاء commit أو تسجيل أب ثانٍ، فيضيع الرابط بالفرع."},{"text":"git merge --no-ff feature","why":"صحيح. يسجّل دائمًا merge commit، فتبقى commits الـ feature مجمّعة على خطها الخاص في الرسم."},{"text":"git merge --all feature","why":"لا يوجد خيار --all في git merge."}],"answer":2}],"exercise":{"kind":"choice","multiple":false,"options":["a","b","c","d"],"correct":["b"],"title":"توقّع نتيجة الدمج","prompt":"هذا هو الموقع الشخصي الآن. الأسهم تتّجه من كل commit إلى أبيه.
\n:::figure قبل الدمج\n
\nلمس الفرعان ملفات مختلفة. تشغّل git merge projects-grid. كيف يبدو الرسم بعد ذلك؟
main أي commits منذ انفصل عنه projects-grid عند b2؟","حين يكون في الطرفين commits جديدة، يصبح الـ fast-forward مستحيلًا."],"explanation":"الـ HEAD على main، إذن main هو الفرع الذي يتحرّك. في الفرعين commits منذ الـ merge base المشترك b2 (c3 على main؛ و d4 و e5 على projects-grid)، لذا فالـ fast-forward مستحيل. ينفّذ Git دمجًا ثلاثيًا انطلاقًا من b2 ويسجّل merge commit جديدًا أبواه c3 و e5. يتحرّك main إليه؛ ويبقى projects-grid على e5 حتى تحذفه.
main بـ fast-forward إلى e5؛ ولا يُنشأ أي commit جديد.","why":"الـ fast-forward يتطلّب أن يكون main سلفًا لـ e5. لكن c3 ليس في سجلّ projects-grid، فلا يستطيع Git أن ينزلق بـ main على خط مستقيم."},"b":{"text":"يظهر merge commit جديد أبواه c3 و e5؛ يتحرّك main إليه ويبقى projects-grid على e5.","why":"صحيح. تحرّك الطرفان منذ b2، فينشئ Git commit له أبوان على الفرع الحالي وحده."},"c":{"text":"يظهر merge commit جديد ويتحرّك main و projects-grid كلاهما إليه.","why":"لا يتحرّك أثناء الدمج إلا الفرع الذي أنت عليه. ويظل projects-grid يشير إلى e5."},"d":{"text":"يُنسخ d4 و e5 بعد c3 بمعرّفات جديدة، فيبقى السجلّ خطيًا.","why":"هذا ما يفعله الـ rebase. أما الـ merge فيحتفظ بالـ commits الأصلية ويصل الخطّين بـ merge commit."}}},"words":641,"readMinutes":4}