GitHub تتيح Stacked Pull Requests في public preview لكل المستودعات
صعوبة تقسيم التغييرات الكبيرة لم تكن في التقسيم بل في صيانة السلسلة بعد كل دمج، وحين تتولى المنصة ذلك يصبح أصغر تغيير مفهوم هو وحدة المراجعة.
أطلقت GitHub في 30 يوليو 2026 خاصية Stacked Pull Requests في public preview لكل المستودعات، دون قائمة انتظار. وتُثبّت بأمر واحد:
gh extension install github/gh-stack
والفكرة أن يُقسَّم العمل إلى طبقات بدل فتح pull request واحد يضم 40 ملفًا. كل PR صغير يقوم فوق الذي تحته، وفرعه الأساسي (base) هو الفرع السابق لا main. ويرى المراجع خريطة للسلسلة كلها، ويستطيع مراجعة أي طبقة وحدها دون انتظار البقية.
لكن الجزء الذي يحل المشكلة الفعلية يحدث عند الدمج. فعند دمج أي PR في السلسلة، تُدمج معه كل الطبقات التي تحته في عملية واحدة. وإذا دُمجت طبقة سفلى أولًا، تُجري الطبقة التي فوقها rebase وتغيّر فرعها الأساسي تلقائيًا.
وهذا تحديدًا ما كان يمنع الفرق من اتباع هذا الأسلوب يدويًا. فتقسيم الفروع ممكن منذ زمن، لكن بمجرد دمج طبقة واحدة، كان على المطور إجراء rebase لكل ما فوقها واحدة تلو الأخرى، وحل التعارضات (conflicts) نفسها مرتين وثلاثًا. أي أن العبء لم يكن في التقسيم، بل في صيانة السلسلة بعد كل دمج.
ويمكن العمل على السلسلة من الموقع أو من تطبيق الموبايل، أما دعم merge queue فما زال يصل تدريجيًا على مدى أسابيع.
والفكرة ليست جديدة، إذ كانت موجودة في Phabricator وفي أدوات مثل Graphite وSapling. الجديد أنها صارت داخل GitHub نفسها. وفي ذلك إقرار بأن وحدة المراجعة ليست الميزة الكاملة، بل أصغر تغيير يمكن فهمه وحده. فبطء المراجعة لا يعود بالضرورة إلى المراجع، بل كثيرًا ما يعود إلى إرسال عمل أسبوع كامل إليه في صفحة واحدة.
المصادر
من عدد الجمعة 17 صفر - 31 يوليو