# GitHub تتيح Stacked Pull Requests في public preview لكل المستودعات

> **المغزى:** صعوبة تقسيم التغييرات الكبيرة لم تكن في التقسيم بل في صيانة السلسلة بعد كل دمج، وحين تتولى المنصة ذلك يصبح أصغر تغيير مفهوم هو وحدة المراجعة.

- المصدر: المغزى (https://almaghza.com/a/2026-07-31-github-stacked-pull-requests-preview/)
- التاريخ: 17 صفر - 31 يوليو 2026 (2026-07-31)
- القسم: فرق ومنتجات
- الوسوم: GitHub، مراجعة الكود، Git، أدوات المطورين

أطلقت 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 نفسها. وفي ذلك إقرار بأن وحدة المراجعة ليست الميزة الكاملة، بل أصغر تغيير يمكن فهمه وحده. فبطء المراجعة لا يعود بالضرورة إلى المراجع، بل كثيرًا ما يعود إلى إرسال عمل أسبوع كامل إليه في صفحة واحدة.

## المصادر

- [إعلان GitHub الرسمي](https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/)
- [توثيق GitHub عن Stacked PRs](https://docs.github.com/en/pull-requests/get-started/about-stacked-prs)