مكدس الفروع

المكدس سلسلة من الفروع يُبنى كل واحد فيها على الذي تحته: main → api → ui. مراجعة ثلاثة طلبات سحب صغيرة خير من مراجعة طلب واحد هائل.

يرسمها Gitcito مسارًا: فرع بداية في الأعلى، ثم محطة لكل مستوى. طلب دمج كل محطة يستهدف المحطة التي فوقها، وأول محطة تحطّ على فرع البداية. تُظهر المحطة كوميتاتها الخاصة، وما إذا كانت بحاجة إلى إعادة تكديس، ورقم طلب الدمج بعد الإرسال.

تحرير المسار

لا يُنفَّذ شيء حتى تضغط «تطبيق». اختيار فرع، تحريك محطة، إزالتها من المسار — كل ذلك يحرّر قائمة على الشاشة. أما العملية الحقيقية فتعيد أساس الفروع وتنتقل إليها، وليست شيئًا تفعله نقرة استكشافية. وحين يستقيم المسار، ينفّذه تطبيق المسار خطوةً واحدة قابلة للتراجع، بينما يعيد تجاهل الرسم إلى ما يقوله المستودع فعلًا.

يُرسم المسار بترتيب الدمج: الفرع الأعلى يُدمج في الذي تحته، وصولًا إلى الفرع الذي تحطّ عليه الكومة.

كل الحقول تعمل بالإكمال أثناء الكتابة: اكتب لتصفية القائمة، و↑/↓ وEnter للاختيار، وما تكتبه خارج القائمة يُحتسب أيضًا — لذا فمرجع بعيد مثل origin/main يصلح فرع بداية.

في العمق هذه التعديلات كلها العملية نفسها: المسار بأكمله، يُسلَّم دفعة واحدة. لذلك تكون الحركة الواحدة تراجعًا واحدًا (⌘Z) لا أثرًا من روابط طُبِّقت نصف تطبيق.

ثمن تعديل المسار

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

وإعادة التكديس هي النصف الآخر من الاتفاق: إنها إعادة أساس طلبتها بالاسم، لذا تتوقف عند التعارض وتسلّمك شاشة التعارضات — وهي أيضًا الطريق إلى الترتيب الذي رفضه Gitcito: احلل هناك ثم انقل المحطة.

يعيد التراجع تشغيل المسار السابق. وهو لا يُحيي الكوميتات القديمة، لأن الجديدة هي العمل نفسه بآباء مختلفين.

دفع الكل

دفع الكل يدفع كل مستوى بـ --force-with-lease ويتوقف عند ذلك — إنه gh stack push من دون فتح أي شيء. أما إرسال الكومة كطلبات دمج فيقوم بالدفع نفسه ثم بعمل طلبات الدمج؛ استخدم دفع الكل حين تريد الفروع على المستودع البعيد ولم تجهز للمراجعة بعد.

إرسال المكدس كطلبات سحب متسلسلة

يسأل الإرسال أولًا: كم طلب دمج سيفتح، وكم سيعيد توجيهه، وعلى أي مستودع بعيد، مع سطر الفرع ← الأساس لكل واحد — ففتح طلبات الدمج فعل علني ويصعب التراجع عنه.وقسم التنقّل المكتوب في كل وصف هو ما يجعل السلسلة مرئية على GitHub الذي لا يعرف شيئًا اسمه كومة.

يجري الإرسال في شاشة خاصة به: الخطة أولًا، ثم التقدّم خطوة بخطوة، وفي النهاية روابط كل طلب دمج ورابط الكومة نفسها.

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

1. يدفع كل مستوى بـ --force-with-lease (الفروع الجديدة تتسامح معه، والمُعاد بناؤها تحتاجه).
2. يفتح طلب سحب لكل مستوى يفتقر إليه — كلٌّ منها مبني على فرع أبيه لا على main، فتعرض كل مراجعة التزاماتها هي وحدها. ويأتي العنوان والوصف من التزامات المستوى نفسه.
3. يعيد توجيه أي طلب سحب قائم انحرف أساسه.
4. يكتب قسم تنقّل في المكدس داخل نص كل طلب سحب، ليرى المراجع في أي مستوى السلسلة كاملة وموضع هذا الطلب فيها.

الإجراء آمن التكرار: اضغطه بعد كل إعادة بناء أو مستوى جديد أو طلب سحب مدموج وسيتقارب — لا يتكرر شيء، ولا يُمَسّ إلا ما انحرف.

حين يندمج طلب السحب السفلي، ينظّف الزر نفسه ما بعده: يُجعل الجذع أبًا لابن المستوى المدموج، ويُلغى تتبّع المستوى، ويُحذف فرعه المحلي (بأمان — فمن المثبت أن الجذع يحتويه)، ويُعاد بناء السلسلة ويُعاد توجيه كل طلب سحب متبقٍّ. ادمج من الأسفل إلى الأعلى، واضغط إرسال، وكرّر.

وعلى GitHub تصير كومة حقيقية أيضًا

الأسس المتسلسلة هي ما تفهمه كل الاستضافات، وعلى GitLab وBitbucket وAzure DevOps ليس هناك سواها. أما GitHub فلديه أكثر: منذ معاينة stacked pull requests صارت الكومة كائنًا على الخادم. وبمجرد وجود طلبات الدمج، يسجّلها Gitcito ككومة — من الأسفل إلى الأعلى — فتحصل على خريطة الكومة في واجهة طلب الدمج، وإعادة أساس متتالية تجري على الخادم، ودمج على الطلب الأعلى يُنزل كل المستويات تحته.

وإن لم يكن المستودع ضمن تلك المعاينة، أو كان الرمز لا يملك إدارة الكومات، فيُتخطى النداء بلا ضجيج: تبقى السلسلة وقسم التنقّل قائمين وحدهما، تمامًا كما على بقية الاستضافات.

إعادة البناء

حين يتغيّر فرع أسفل — كأن تعالج ملاحظات المراجعة على api — يصبح كل فرع فوقه مبنيًا على أساس خاطئ. تعيد إعادة البناء أساس السلسلة كلها على التوالي عبر rebase --onto، فلا تؤدي إعادة كتابة الأب إلى تكرار الالتزامات داخل أبنائه. بعد إعادة البناء اضغط إرسال مجددًا: فيدفع المستويات المُعاد كتابتها دفعًا قسريًا وتتحدّث طلبات السحب في مكانها.

الحدود

• الإرسال يعمل حاليًا على GitHub فقط (الإنشاء يعمل على المضيفين الأربعة كلهم، لكن إعادة التوجيه وتحديث النصوص يحتاجان واجهة GitHub البرمجية).
• تنظيف اندماج القاع يرى اندماجات الدمج وإعادة الأساس عبر النسب، ويرى اندماجات السحق (squash) بسؤال GitHub عمّا إذا كان طلب سحب الفرع قد اندمج — فمع رمز GitHub يُنظَّف كل أسلوب دمج. على المضيفين الآخرين، أو من دون رمز، يظل المستوى المدموج سحقًا بحاجة إلى إلغاء تتبّع يدوي. واجلب أولًا أيضًا — ففحص النسب يقرأ الجذع كما كان عند آخر جلب.
• يُصان قسم المكدس في نص طلب السحب بين علامتين خفيتين — ويبقى وصفك أنت فوقه محفوظًا.
• إعادة الترتيب وتغيير الجذع يعيدان كتابة التاريخ في كل مستوى يمسّانه. الفروع فروعك، والمستويات غير المدفوعة لا تكلّف شيئًا، لكن مستوى تحت المراجعة سيتلقى دفعًا قسريًا في الإرسال التالي.
• يتحرك المستوى مرتبة واحدة في المرة. تبديلان يعنيان عمليتَي rebase، والتوقف في المنتصف حالة مفهومة؛ أما سحب يهبط بعد ثلاث مراتب فلا.
• تُعاد قاعدة المحطة (rebase)، لذا فالفرع الذي تحطّ عليه الكومة لا يكون محطة فيها أبدًا، وكذلك الفرع المحمي (main وmaster ما لم تغيّر القائمة). كلاهما يُرفض بدل إعادة كتابة تاريخ مشترك في صمت.
• قبل فتح أي شيء، يسأل الإرسال المستودع البعيد أي الفروع وصلت فعلًا ويسمّي ما لم يصل. يردّ GitHub على رأس مفقود بعبارة جافة هي "Validation Failed"، وهي لا تفيد أحدًا. ويُفحص كذلك الفرع الذي تحطّ عليه الكومة: إن كان محليًا فقط، يعرض الإرسال دفعه والمتابعة.

أين تعيش الروابط

تُحفظ روابط الآباء في إعدادات git، فتسافر مع المستودع وتنجو من إعادة الاستنساخ. لا شيء منها يعيش في أي خدمة.

انظر أيضًا: إعادة الأساس التفاعلية · الاستضافة وطلبات السحب