عندما ينفذ وكيل برمجي ميزة كبيرة، قد ينتهي العمل بطلب سحب واحد يضم أكثر من ألف سطر من التغييرات، ما يجعل مراجعته بطيئة ويزيد احتمال وصول الكود إلى الدمج بعد تدقيق محدود. تقترح GitHub بدلاً من ذلك استخدام طلبات السحب المت stacked pull requests، عبر تقسيم الميزة إلى طبقات منطقية مرتبة، بحيث يعالج كل طلب سحب concern واحداً ويعتمد على الطبقة السابقة.
تقول GitHub إن وكلاء البرمجة يزيدون الحاجة إلى اتخاذ قرار واضح بشأن هيكلة طلبات السحب، بدلاً من إزالة هذه الحاجة. ويستند المنشور كذلك إلى توقع من Gartner بأن تقود هذه الوكلاء إلى زيادة في الإنتاجية قدرها 50% عبر كل مراحل دورة حياة تطوير البرمجيات بحلول عام 2028، مع بقاء تنظيم العمل ومراجعته مسؤولية تحتاج إلى تصميم مقصود.
مشكلة الطلب الواحد الكبير
يستخدم المنشور مثالاً لمساعد تسوق يُراد تزويده ببحث عن المنتجات. يبدأ التطبيق ببيانات منتجات غير متسقة وموزعة داخل المكونات، ومن دون وحدة كتالوج أو واجهة API أو طبقة بيانات. في سير العمل التقليدي، ينشئ وكيل البرمجة فرعاً واحداً وينفذ النموذج والبيانات الأولية ومسار API والتحقق وربط العميل وواجهة المستخدم وحالات الفراغ والخطأ، إضافة إلى الاختبارات، داخل طلب سحب واحد.
قد ينتج عن ذلك فرق يتجاوز 1,000 سطر، مع وصف طويل لكنه لا يوفر بالضرورة سياقاً كافياً للمراجع. وبحسب المثال، يصبح الطلب الكبير صعب المراجعة، ويفقد المراجعون السياق، وتتراجع جودة الملاحظات، ويتباطأ الدمج، كما تزداد فرص التعارضات قبل وصول الميزة إلى المستودع.
بناء السلسلة طبقة فوق أخرى
تبدأ العملية بتحديد قاعدة السلسلة، وهي خطوة تؤثر في تقييم فحوص CI وقواعد الدمج طوال دورة إدارة السلسلة. بعد ذلك توضع وحدة العمل التأسيسية الأقرب إلى القاعدة، ثم تُبنى الأعمال التابعة فوقها. وفي مثال بحث المنتجات، تتوزع المسؤوليات على البيانات وواجهة API والربط وتجربة المستخدم، ما يتيح أيضاً توجيه كل طبقة إلى المراجعين الأكثر ملاءمة لها.
تتكون السلسلة المقترحة من أربع طبقات:
- أساس كتالوج البيانات: ينشئ وكيل نمذجة البيانات الفرع feat/catalog-data فوق main، ويضيف النموذج والبيانات ووسائل الوصول، ثم يشغل عمليات التحقق قبل تثبيت الطبقة.
- واجهة API للبحث عن المنتجات: يضيف وكيل الواجهة الخلفية الفرع feat/search-api فوق الطبقة الأولى، مع اختبار واجهة API والتحقق من مدخلاتها وثبات عقد الاستجابة ومعالجة حالات الخطأ والنتائج الفارغة.
- ربط المحادثة بواجهة API: ينشئ وكيل الواجهة الأمامية الفرع feat/chat-grounding فوق الطبقة الثانية، ثم يشغل اختبارات المتصفح باستخدام Playwright للتأكد من أن الإجابات تعتمد على استجابات حقيقية من واجهة API.
- واجهة المستخدم والاستشهادات: يضيف الوكيل نفسه الفرع feat/grounded-ui فوق الطبقة الثالثة، مع التحقق من ارتباط كل استشهاد بمنتج حقيقي وتغطية حالات التحميل والفراغ والخطأ.
إعداد أدوات GitHub والوكلاء
تتيح GitHub تشغيل دعمها الأصلي لطلبات السحب المت stacked pull requests من واجهة طلب السحب، كما يمتد إلى الطرفية عبر إضافة gh stack. يثبت الدليل الإضافة بالأمر التالي:
gh extension install github/gh-stack
ولتعليم وكلاء البرمجة كيفية إنشاء السلاسل وإدارتها، يورد الدليل الأمر:
gh skill install github/gh-stack
كما يطرح بديلاً باستخدام:
npx skills add github/gh-stack
بعد تجهيز الوكلاء، ينبغي التأكد من وجود CI، لأن كل طلب سحب في السلسلة يُقيّم مقابل قاعدة السلسلة، وتُشغّل الفحوص لكل طبقة.
رفع السلسلة ومراجعتها
بعد اكتمال الفروع المحلية الأربعة، تُرفع إلى المستودع البعيد باستخدام gh stack push، ثم تُنشأ طلبات السحب المرتبطة عبر gh stack submit. وتعرض GitHub في أعلى كل طلب خريطة للسلسلة، تعمل كوسيلة تنقل بين الطبقات.
تقترح GitHub قراءة السلسلة من الأعلى إلى الأسفل لفهم الهدف النهائي، ثم مراجعتها من الأسفل إلى الأعلى، لأن كل طبقة تعتمد على فهم الطبقة السابقة. بهذه الطريقة لا يواجه المراجع فرقاً واحداً يتجاوز 1,720 سطراً، بل أهدافاً أصغر ومستقلة نسبياً يمكن توزيعها على مراجعين مختلفين.
التعامل مع التعديلات والتعارضات
إذا اكتشف المراجع مشكلة في الطبقة الأولى، تُعاد الملاحظة إلى الوكيل المسؤول عن فرع البيانات، ثم تُطبّق التعديلات وتُختبر وتُثبت وتُرفع. وعندما يتغير فرع أساسي بعد مراجعة الطبقات الأعلى، قد تشير GitHub إلى أن بعض فروع السلسلة تباعدت وأنه لا يمكن دمج السلسلة قبل إعادة الأساس.
تظهر في واجهة GitHub إمكانية Rebase stack بنقرة واحدة، لكن المنشور يحذر من أن إعادة الأساس عبر خوادم GitHub تغيّر صاحب عملية الالتزام إلى المستخدم الذي نقر الزر، وتنتج التزامات غير موقعة. وقد يؤدي ذلك إلى كسر متطلبات حماية الفروع التي تشترط التزامات موقعة.
يوصي الدليل بدلاً من ذلك بتنفيذ العملية محلياً باستخدام gh stack rebase لحل التعارضات تفاعلياً مع إعدادات Git الخاصة بالمستخدم، ثم تشغيل gh stack push. وبعد ذلك يُستخدم gh stack sync لمزامنة السلسلة؛ إذ يجلب التغييرات من origin، ويعيد ترتيب الفروع المتعاقبة فوق الالتزام الجديد، ويدفع الفروع المعاد ترتيبها ويحدّث حالة طلبات السحب. عند اكتمال العملية، تعاد فحوص CI على الطبقات وتستقر السلسلة في مسار قابل للدمج من main إلى feat/grounded-ui.