# Развертывание запросов на вытягивание с накоплением в организации

Запросы на вытягивание с накоплением помогают вашей организации поддерживать качество проверки, так как команды предоставляют большие изменения в небольших, проверяемых уровнях, сохраняя необходимые проверки и проверки состояния.

> \[!NOTE]
> Запросы на вытягивание с накоплением находятся и Публичный предварительный просмотр подвергаются изменению.

Запросы на вытягивание с накоплением позволяют разработчикам прервать большие изменения в цепочке небольших, ориентированных на вытягивание запросов, которые создаются друг на друга. Такой подход может помочь вашей организации поддерживать качество проверки, так как разработчики создают больше кода, в том числе с Copilot другими агентами программирования.

Запросы на вытягивание с накоплением **не требуют установки или включения**. Если ваша команда уже использует запросы на вытягивание, они могут создать стек сегодня. Приведенные ниже действия помогут подготовить существующие элементы управления и поддерживать плавное развертывание, а не включить функцию.

В этом руководстве показано, соответствуют ли запросы на вытягивание с накоплением в организации, убедитесь, что основы находятся на месте, пилотируют рабочий процесс, поддерживают внедрение и обновление программных средств. Основные сведения о запросах на вытягивание с накоплением см. в разделе [Сведения о запросах на вытягивание с накоплением](/ru/pull-requests/get-started/about-stacked-prs).

## 1. Определите, соответствуют ли запросы на вытягивание с накоплением

Используйте эту быструю самостоятельную проверку перед вложением в развертывание:

* Создают ли ваши команды большой объем кода либо сами, либо с Copilot другими агентами кодирования?
* Работают ли ваши команды над большими функциями, особенно внутри monorepos, которые трудно разделить на независимые запросы на вытягивание?

Если вы описываете команды, запросы на вытягивание с накоплением могут помочь им отправлять зависимые изменения в небольших единицах без ожидания объединения каждого запроса на вытягивание перед началом следующего, если их работа соответствует одному ограничению: каждый запрос на вытягивание в стеке должен находиться в одном репозитории, следуя одной линейной цепочке ветвей. Стеки не могут включать в себя вилки или ветвления структур, поэтому команды, которые сильно полагаются на вилки для вкладов, должны сохранить эти вклады за пределами стеков на данный момент.

## 2. Убедитесь, что основы установлены

Каждый запрос на вытягивание в **стеке вычисляется по базе стека** (как правило `main`), а не ветвью, на который он непосредственно предназначен. Существующие правила защиты ветви или наборы правил и рабочие процессы CI применяются автоматически:

* Обязательные проверки, необходимые проверки состояния и CODEOWNERS применяются к базовой ветви стека для каждого запроса на вытягивание в стеке.
* GitHub Actions Рабочий процесс, который активирует `pull_request` события, предназначенные для ветви репозитория по умолчанию, выполняется для **каждого** запроса на вытягивание в стеке, поэтому существующая конфигурация CI не требует изменения.
* Метаданные стека доступны в выражениях рабочих `github.event.pull_request.stack`процессов, если вы хотите настроить поведение рабочего процесса специально для запросов на вытягивание с накоплением. Так как рабочий процесс выполняется один раз на запрос на вытягивание в стеке, команды могут использовать эти метаданные для ограничения дорогостоящих заданий и снижения использования CI. Дополнительные сведения см. в разделе [Оптимизация CI для запросов на вытягивание с накоплением](/ru/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).

Одно необязательное дополнение стоит рассмотреть: если разработчикам необходимо переупорядочение запросов на вытягивание после создания стека без его растворения, принять `gh stack` расширение для GitHub CLI. Для переупорядочения на месте требуется `gh stack modify`; GitHub на веб-сайте разработчики должны отменить запросы на вытягивание и повторно создать стек в нужном порядке.

Стек также закрывается автоматически после объединения каждого запроса на вытягивание. Если команда добавляет новые ветви поверх объединенного стека и выполняется `gh stack submit`, интерфейс командной строки запускает новый стек с той же базовой ветвью. Он не расширяет исходный код. Команды, которые хотят продолжать работать в наборе изменений, должны планировать открытие стека до завершения всей работы.

Полный список правил и требований см. в разделе [Запросы на вытягивание с накоплением](/ru/pull-requests/reference/stacked-pull-requests).

## 3. Пилотный проект с небольшой группой

Выберите небольшую группу разработчиков, которые создают большой объем кода либо сами, либо через Copilot другие агенты программирования. Попросите группу использовать реальную репрезентативную функцию для пилотного проекта вместо примера с возможностью удаления.

Чтобы создать свой первый стек, направляйте пользователей в [Краткое руководство по запросам на вытягивание с накоплением](/ru/pull-requests/get-started/stacked-prs-quickstart). После пилотного проекта соберите отзывы от разработчиков и рецензентов:

* Как планирование стека вписывается в существующий рабочий процесс и требуется ли разработчикам переупорядочение на месте, для которого требуется `gh stack` расширение
* Если поток проверки чувствовал себя разными теперь, что каждый запрос на вытягивание в стеке несет свои собственные необходимые проверки и проверки состояния
* Все пробелы в поддержке или документации, с которые они столкнулись

## 4. Развертывание и поддержка внедрения

После пилотного проекта поделитесь повседневными рекомендациями по созданию, просмотру, управлению и слиянию стеками команд: [Запросы на вытягивание с накоплением](/ru/pull-requests/how-tos/stacked-pull-requests).

Как отмечалось на шаге 2, рекомендуется `gh stack`GitHub CLI использовать расширение, когда разработчикам необходимо переупорядочение стека, не растворяя его. Команды, которые не используют локальные инструменты CLI, могут отменить и повторно создать стек в нужном порядке на GitHub веб-сайте.

Teams, создающая большой объем созданного ИИ кода, одного из сигналов соответствия на шаге 1, может найти рекомендации по стеку изменений от агентов программирования в [Код, созданный Стеком ИИ, в запросах на вытягивание](/ru/copilot/tutorials/stack-ai-generated-code-in-pull-requests).

## 5. Обновление программного средства

Чтобы обеспечить внедрение, просмотрите все встроенные средства, боты или панели мониторинга, которые создают, объединяют или отслеживают запросы на вытягивание программными средствами и обновляют их для учета стека.

Если ваша организация предоставляет внутренний интерфейс командной строки или другое средство разработчика, вы можете использовать API Stacks для интеграции создания стека и управления ими в существующие средства, а не требовать от разработчиков внедрения `gh stack`.

> \[!IMPORTANT]
> Для объединения запроса на вытягивание с накоплением требуется API асинхронного слияния. Устаревшие конечные точки слияния запросов на вытягивание не могут объединить стек. Если организация объединяет запросы на вытягивание программным способом, например с помощью встроенных инструментов или ботов ChatOps, обновите это средство для вызова API асинхронного слияния, который поддерживает как стек, так и обычные запросы на вытягивание, прежде чем развертывать стекированные запросы на вытягивание. См [. раздел AUTOTITLE](/ru/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).

Вы также можете программно отслеживать действия стека, например на панелях мониторинга, ботах или внутренних инструментах.

* **REST API**: каждый запрос на вытягивание, возвращаемый API, включает `stack` объект, когда он принадлежит стеку, показывающий число, размер, положение запроса на вытягивание внутри него и базовую ветвь стека. Выделенный API стека (`GET /repos/{owner}/{repo}/stacks`) также перечисляет каждый стек в репозитории или конкретный стек, содержащий заданный запрос на вытягивание. См [. раздел AUTOTITLE](/ru/pull-requests/reference/stacked-pull-requests-apis-and-webhooks).
* **Веб-перехватчики**: `pull_request` полезные данные веб-перехватчика включают тот же `stack` объект, когда запрос на вытягивание принадлежит стеку.
  `stacked` Выделенное действие запускается при первом добавлении запроса на вытягивание в стек, чтобы вы могли реагировать на момент форм стека.

В обоих случаях `stack` поле предназначено `null` для автономных запросов на вытягивание, поэтому существующие интеграции, которые не ожидают, что стеки продолжают работать без изменений.