شرح git rebase التفاعلي بواجهة رسومية: دمج الإيداعات (squash) وتعديلها وترتيبها وحذفها

git rebase التفاعلي (إعادة التأسيس التفاعلية أو interactive rebase) هو طريقة Git لإعادة كتابة إيداعات فرعك قبل مشاركتها، وفي الواجهة الرسومية تنجزه من قائمة مرئية بدل ملف نصي: تختار إيداعًا تبدأ منه، وتمنح كل إيداع فوقه إجراءً (pick أو squash أو fixup أو reword أو edit أو drop)، وتسحب الإيداعات إلى ترتيب جديد، ثم يعيد Git تطبيقها. إنها العملية نفسها التي ينفّذها الأمر git rebase -i، فالنتيجة مطابقة لسطر الأوامر. في GitTree انقر بالزر الأيمن على الإيداع الواقع مباشرة أسفل الإيداعات التي تريد تغييرها، واختر إعادة تأسيس تفاعلية للإيداعات التي تعلوه…، وحدّد الإجراءات ثم انقر بدء إعادة التأسيس. وإن جاءت النتيجة خاطئة، يعيد التراجع (Undo) الفرع كما كان.

يغطي هذا الشرح كل إجراء، وثلاث طرق لدمج الإيداعات (squash)، والأوامر المقابلة، وautosquash، وشبكة الأمان. الصور من محرر إعادة التأسيس التفاعلية في GitTree، وهو برنامج Git بواجهة رسومية مجاني لأنظمة ماك (Mac) وويندوز (Windows) ولينكس (Linux)، لكن سلوك Git الموصوف هنا واحد في أي أداة.

ما الذي يفعله git rebase التفاعلي، ومتى تستخدمه؟

يكتفي rebase العادي بنقل سلسلة من الإيداعات إلى قاعدة جديدة. أما rebase التفاعلي فيتيح لك تعديل السلسلة في الطريق: يعرض Git الإيداعات التي سيعيد تطبيقها، فتعدّل القائمة، ثم يعيد بناء الفرع وفقها. كل إيداع تُعاد كتابته يحصل على معرّف (id) جديد، ولذلك فالوقت المناسب لإعادة التأسيس التفاعلية هو ما قبل مشاركة عملك مع الآخرين. أشهر دواعي استخدامه:

• دمج سلسلة إيداعات مثل «wip» و«fix typo» و«address review» في إيداع واحد ذي معنى قبل فتح طلب سحب (pull request).
• إعادة صياغة رسالة إيداع فيها خطأ إملائي أو ينقصها رقم التذكرة أو ملخصها غامض.
• ضمّ تعديل منسيّ إلى الإيداع الذي ينتمي إليه، كي يُبنى كل إيداع وحده دون أخطاء.
• إعادة ترتيب الإيداعات كي تسبق إعادة الهيكلة (refactor) الميزة التي تعتمد عليها.
• إسقاط إيداع أُضيف لتتبّع الأخطاء (debugging) أو تجربة لا ينبغي أن تصل إلى الفرع الرئيسي.

pick وsquash وfixup وreword وedit وdrop: شرح إجراءات rebase التفاعلي

كل سطر في خطة rebase التفاعلي إيداعٌ واحد وإجراءٌ واحد. هذه هي الإجراءات التي ستستخدمها يوميًا (ولملف المهام في Git إجراءات أخرى للبرمجة النصية مثل exec وbreak):

الترتيب مهم، وهو عكس `git log`. تعرض الخطة الإيداع الأقدم في الأعلى بترتيب إعادة التطبيق، بينما يعرض git log ومعظم مخططات الإيداعات الأحدث أولًا. يندمج squash أو fixup دائمًا في الإيداع الذي فوقه مباشرة، أي الأقدم. وإن وصل squash إلى أعلى القائمة دون إيداع يندمج فيه، يرفض GitTree البدء حتى تنقله أسفل إيداع تُبقي عليه.

المقابل في سطر الأوامر: git rebase -i

في سطر الأوامر تحدد الإيداع الواقع مباشرة أسفل الإيداعات التي تريد تغييرها: إما بالعدّ رجوعًا من HEAD، أو بالنقطة التي تفرّع عندها فرعك عن main.

# rewrite the last 5 commits
git rebase -i HEAD~5

# rewrite everything since the branch left main, without moving its base
git rebase -i $(git merge-base main HEAD)

يفتح Git محررك بقائمة مهام (todo list). القائمة التالية هي الخطة نفسها الظاهرة في الصورة أدناه: الإيداع الثاني يُدمج في الأول، والرابع يحصل على رسالة جديدة.

pick f2cd67d chore(deps): upgrade Next.js and React
squash 19a1104 ci: cache pnpm store and run tests in parallel
pick f52edc8 refactor(api): extract repository layer from handlers
reword 05dfac2 feat(api): rate limit public endpoints
pick bf2385e fix(web): focus trap in the invite dialog

احفظ الملف وأغلقه فيبدأ Git إعادة التطبيق. يطلب منك رسالة الدمج والرسالة المعاد صياغتها، ويتوقف عند أي خطوة edit أو تعارض، فتختار المتابعة أو الإلغاء:

git rebase --continue   # after amending or resolving a conflict
git rebase --abort      # stop and put the branch back where it was

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

كيف تدمج الإيداعات (squash) في واجهة Git رسومية

الجواب المختصر عن سؤال كيف تدمج الإيداعات: ضعها متجاورة، واترك أولها pick، وعلّم البقية squash أو fixup، ثم أعِد التطبيق. يسمّي GitTree هذا الإجراء «ضمّ» في واجهته العربية، ويمنحك ثلاث طرق للوصول إليه.

دمج مجموعة إيداعات في محرر rebase

افتح المحرر من الإيداع الواقع أسفل المجموعة، واجعل أول إيداع فيها pick والبقية squash، أو fixup إن لم ترد رسائلها. اسحب الإيداعات الشاردة إلى مكانها إن لم تكن المجموعة متجاورة. يعرض GitTree كل مجموعة فيها squash بالشكل الذي سيكون عليه الإيداع الناتج، مع الرسالة المجمّعة في مربع يمكنك تحريره.

حدّد الإيداعات في المخطط واختر «ضمّ الإيداعات»

للدمج السريع، حدّد إيداعين متتاليين أو أكثر من الفرع الحالي في المخطط، وانقر بالزر الأيمن واختر ضمّ الإيداعات (Squash Commits). ينفّذ GitTree عملية rebase نيابةً عنك، ويستطيع التراجع إعادة الإيداعات منفصلة كما كانت. وفي القائمة نفسها إجراءات تعيد كتابة إيداع واحد بخطوة واحدة: تحرير رسالة الإيداع… وإسقاط الإيداع… ونقل الإيداع لأعلى ونقل الإيداع لأسفل. تعمل هذه الاختصارات على الإيداعات التي لم تصل إلى مستودع بعيد بعد؛ أما الإيداعات المدفوعة فاستخدم لها المحرر، فهو يطلب تأكيدك أولًا.

الدمج عند قبول طلب السحب

إن كان فريقك يكتفي بإيداع واحد لكل طلب سحب، فقد لا تحتاج إلى إعادة كتابة الفرع أصلًا: يستطيع عرض طلبات السحب في GitTree الدمج بطريقة squash، ويبقى فرعك المحلي كما هو.

إيداعات fixup وautosquash: أصلح إيداعًا قديمًا دون ترتيب يدوي

أثناء العمل، أودِع كل تصحيح صغير على أنه fixup للإيداع الذي ينتمي إليه، فيضع Git في عنوانه fixup! متبوعة بعنوان الإيداع الأصلي. لاحقًا، ينقل rebase تفاعلي واحد مع autosquash كل fixup إلى أسفل هدفه مباشرة ويعلّمه fixup، فلا يبقى عليك سوى مراجعة القائمة والبدء.

# record a correction for an earlier commit
git commit --fixup=05dfac2

# correct the commit and replace its message too
git commit --fixup=amend:05dfac2

# later: fold every fixup! and amend! commit into its target
git rebase -i --autosquash main

# turn autosquash on for every interactive rebase
git config --global rebase.autoSquash true

في GitTree، نفّذ هذه الأوامر في الطرفية المدمجة أسفل المخطط، أو اكتب fixup! ثم مسافة ثم العنوان الأصلي في مربع رسالة الإيداع؛ فـGit يطابق إيداعات fixup بالعنوان، والطريقتان تنشئان الإيداع نفسه. ومع تفعيل خيار رتّب إيداعات fixup! وsquash! وamend! يُفتح المحرر مرتّبًا مسبقًا، وما تراه هو بالضبط ما ينفّذه Git.

يتحول إيداع amend! إلى fixup -C في الخطة («ضمّ مع استخدام رسالته» في GitTree): تُضمّ تغييراته وتحل رسالته محل رسالة الهدف. وبحسب توثيق git-commit، لا يغيّر أيٌّ من النوعين مؤلف الإيداع الأصلي.

هل rebase التفاعلي آمن؟ التراجع وreflog وforce-with-lease

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

التراجع عن rebase انتهى

يحفظ GitTree لقطة من الفرع قبل كل rebase، فيعيده زر التراجع في شريط الأدوات بنقرة واحدة، ومعه الفروع الأخرى التي نقلتها العملية عبر update-refs، ما دام الفرع لم يتحرك منذ ذلك الحين. ويشرح مقال كيف تتراجع عن git reset أو rebase أو commit بقية شبكة الأمان. وفي سطر الأوامر:

# still in the middle of the rebase
git rebase --abort

# already finished: go back to the tip from before the rebase
git reflog show --date=relative
git reset --hard ORIG_HEAD

يضبط Git المرجع ORIG_HEAD على الطرف القديم للفرع عند بدء rebase، لكن أي git reset يُنفَّذ أثناء العملية (لتقسيم إيداع مثلًا) يغيّره. وبعد انتهاء rebase مباشرةً يظل @{1}، أي الموضع السابق للفرع الحالي، يشير إلى الطرف القديم، فيؤدي git reset --hard @{1} الغرض نفسه. يتخلص git reset --hard من التغييرات غير المودَعة، فأودِعها أو خبّئها أولًا.

إعادة كتابة إيداعات دفعتها بالفعل

يضع GitTree على الإيداعات الموجودة على مستودع بعيد علامة «على مستودع بعيد»، ويطلب تأكيدك قبل إعادة كتابتها. بعد ذلك يُرفض الدفع (push) العادي، فتحتاج إلى دفع قسري. استخدم صيغة lease التي لا تكتب فوق الفرع البعيد إلا إن كان ما زال يشير إلى حيث رأيته آخر مرة:

git push --force-with-lease

# safer when something fetches in the background
git push --force-with-lease --force-if-includes

قد يحدّث جلبٌ (fetch) يجري في الخلفية فرعَ التتبع البعيد لديك فيُضعف هذا الشرط، لذا يقترح توثيق git-push إضافة --force-if-includes. وفي GitTree يستخدم الدفع القسري دائمًا --force-with-lease مثبّتًا على طرف الفرع البعيد الذي يظهر لك عند التأكيد، ويُحفظ هذا الطرف محليًا تحت refs/ogt/trash فلا تضيع الإيداعات التي يزيلها الدفع من المستودع البعيد. لكن التراجع (Undo) لا يستطيع عكس دفع قسري، لأنه غيّر المستودع البعيد.

حين تتوقف خطوة: edit والتعارضات

تتوقف العملية عند خطوة edit، أو عند إيداع لم يعد يُطبَّق بسلاسة. يعرض GitTree تقدّم الخطة وشريط تنبيه للمتابعة أو الإيقاف. وتُفتح التعارضات في المحرر الثلاثي المشروح في حل تعارضات الدمج بواجهة رسومية. وأثناء rebase يعكس Git طرفي الدمج (merge): يصبح «ours» هو الفرع الذي تعيد التأسيس عليه، و«theirs» هو إيداعك أنت، ولهذا يسمّي GitTree الطرفين «يُعاد التأسيس عليه» و«إيداعك».

نصائح لسجل إيداعات نظيف قبل طلب السحب

• اجعل كل إيداع يُبنى وتنجح اختباراته وحده، وافصل التغييرات غير المترابطة: إيداع لإعادة الهيكلة وآخر للميزة.
• أعِد التأسيس على أحدث نسخة من main قبل فتح طلب السحب، كي لا يرى المراجعون إلا تغييراتك.
• تعمل بفروع متراكبة (stacked branches)؟ فعّل update-refs كي تنتقل الفروع المبنية على فرعك مع الإيداعات المعاد كتابتها.
• إن احتوى النطاق على إيداع دمج (merge commit)، يعرضه GitTree لكنه لا يعيد كتابته؛ استخدم git rebase -i --rebase-merges لهذه الحالة.
• راجع النتيجة في مخطط الإيداعات قبل الدفع، ودع أداة الذكاء الاصطناعي التي تستخدمها في سطر الأوامر تصوغ الرسائل، كما في رسائل الإيداع بالذكاء الاصطناعي مع Claude Code وCodex.

GitTree مجاني اليوم، بما في ذلك المستودعات الخاصة، على macOS وWindows وLinux، بواجهة عربية كاملة من اليمين إلى اليسار وأخرى إنجليزية. يحتاج إلى حساب GitTree مجاني وإلى Git 2.39 أو أحدث. حمّله من صفحة التحميل، أو قارن أولًا بين أفضل برامج Git بواجهة رسومية.