{"meta":{"title":"Развертывание запросов на вытягивание с накоплением в организации","intro":"Запросы на вытягивание с накоплением помогают вашей организации поддерживать качество проверки, так как команды предоставляют большие изменения в небольших, проверяемых уровнях, сохраняя необходимые проверки и проверки состояния.","product":"Запросы на включение внесенных изменений","breadcrumbs":[{"href":"/ru/pull-requests","title":"Запросы на включение внесенных изменений"},{"href":"/ru/pull-requests/tutorials","title":"Учебники"},{"href":"/ru/pull-requests/tutorials/roll-out-stacked-prs","title":"Развертывание стекаемых PR"}],"documentType":"article"},"body":"# Развертывание запросов на вытягивание с накоплением в организации\n\nЗапросы на вытягивание с накоплением помогают вашей организации поддерживать качество проверки, так как команды предоставляют большие изменения в небольших, проверяемых уровнях, сохраняя необходимые проверки и проверки состояния.\n\n> \\[!NOTE]\n> Запросы на вытягивание с накоплением находятся и Публичный предварительный просмотр подвергаются изменению.\n\nЗапросы на вытягивание с накоплением позволяют разработчикам прервать большие изменения в цепочке небольших, ориентированных на вытягивание запросов, которые создаются друг на друга. Такой подход может помочь вашей организации поддерживать качество проверки, так как разработчики создают больше кода, в том числе с Copilot другими агентами программирования.\n\nЗапросы на вытягивание с накоплением **не требуют установки или включения**. Если ваша команда уже использует запросы на вытягивание, они могут создать стек сегодня. Приведенные ниже действия помогут подготовить существующие элементы управления и поддерживать плавное развертывание, а не включить функцию.\n\nВ этом руководстве показано, соответствуют ли запросы на вытягивание с накоплением в организации, убедитесь, что основы находятся на месте, пилотируют рабочий процесс, поддерживают внедрение и обновление программных средств. Основные сведения о запросах на вытягивание с накоплением см. в разделе [Сведения о запросах на вытягивание с накоплением](/ru/pull-requests/get-started/about-stacked-prs).\n\n## 1. Определите, соответствуют ли запросы на вытягивание с накоплением\n\nИспользуйте эту быструю самостоятельную проверку перед вложением в развертывание:\n\n* Создают ли ваши команды большой объем кода либо сами, либо с Copilot другими агентами кодирования?\n* Работают ли ваши команды над большими функциями, особенно внутри monorepos, которые трудно разделить на независимые запросы на вытягивание?\n\nЕсли вы описываете команды, запросы на вытягивание с накоплением могут помочь им отправлять зависимые изменения в небольших единицах без ожидания объединения каждого запроса на вытягивание перед началом следующего, если их работа соответствует одному ограничению: каждый запрос на вытягивание в стеке должен находиться в одном репозитории, следуя одной линейной цепочке ветвей. Стеки не могут включать в себя вилки или ветвления структур, поэтому команды, которые сильно полагаются на вилки для вкладов, должны сохранить эти вклады за пределами стеков на данный момент.\n\n## 2. Убедитесь, что основы установлены\n\nКаждый запрос на вытягивание в **стеке вычисляется по базе стека** (как правило `main`), а не ветвью, на который он непосредственно предназначен. Существующие правила защиты ветви или наборы правил и рабочие процессы CI применяются автоматически:\n\n* Обязательные проверки, необходимые проверки состояния и CODEOWNERS применяются к базовой ветви стека для каждого запроса на вытягивание в стеке.\n* GitHub Actions Рабочий процесс, который активирует `pull_request` события, предназначенные для ветви репозитория по умолчанию, выполняется для **каждого** запроса на вытягивание в стеке, поэтому существующая конфигурация CI не требует изменения.\n* Метаданные стека доступны в выражениях рабочих `github.event.pull_request.stack`процессов, если вы хотите настроить поведение рабочего процесса специально для запросов на вытягивание с накоплением. Так как рабочий процесс выполняется один раз на запрос на вытягивание в стеке, команды могут использовать эти метаданные для ограничения дорогостоящих заданий и снижения использования CI. Дополнительные сведения см. в разделе [Оптимизация CI для запросов на вытягивание с накоплением](/ru/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).\n\nОдно необязательное дополнение стоит рассмотреть: если разработчикам необходимо переупорядочение запросов на вытягивание после создания стека без его растворения, принять `gh stack` расширение для GitHub CLI. Для переупорядочения на месте требуется `gh stack modify`; GitHub на веб-сайте разработчики должны отменить запросы на вытягивание и повторно создать стек в нужном порядке.\n\nСтек также закрывается автоматически после объединения каждого запроса на вытягивание. Если команда добавляет новые ветви поверх объединенного стека и выполняется `gh stack submit`, интерфейс командной строки запускает новый стек с той же базовой ветвью. Он не расширяет исходный код. Команды, которые хотят продолжать работать в наборе изменений, должны планировать открытие стека до завершения всей работы.\n\nПолный список правил и требований см. в разделе [Запросы на вытягивание с накоплением](/ru/pull-requests/reference/stacked-pull-requests).\n\n## 3. Пилотный проект с небольшой группой\n\nВыберите небольшую группу разработчиков, которые создают большой объем кода либо сами, либо через Copilot другие агенты программирования. Попросите группу использовать реальную репрезентативную функцию для пилотного проекта вместо примера с возможностью удаления.\n\nЧтобы создать свой первый стек, направляйте пользователей в [Краткое руководство по запросам на вытягивание с накоплением](/ru/pull-requests/get-started/stacked-prs-quickstart). После пилотного проекта соберите отзывы от разработчиков и рецензентов:\n\n* Как планирование стека вписывается в существующий рабочий процесс и требуется ли разработчикам переупорядочение на месте, для которого требуется `gh stack` расширение\n* Если поток проверки чувствовал себя разными теперь, что каждый запрос на вытягивание в стеке несет свои собственные необходимые проверки и проверки состояния\n* Все пробелы в поддержке или документации, с которые они столкнулись\n\n## 4. Развертывание и поддержка внедрения\n\nПосле пилотного проекта поделитесь повседневными рекомендациями по созданию, просмотру, управлению и слиянию стеками команд: [Запросы на вытягивание с накоплением](/ru/pull-requests/how-tos/stacked-pull-requests).\n\nКак отмечалось на шаге 2, рекомендуется `gh stack`GitHub CLI использовать расширение, когда разработчикам необходимо переупорядочение стека, не растворяя его. Команды, которые не используют локальные инструменты CLI, могут отменить и повторно создать стек в нужном порядке на GitHub веб-сайте.\n\nTeams, создающая большой объем созданного ИИ кода, одного из сигналов соответствия на шаге 1, может найти рекомендации по стеку изменений от агентов программирования в [Код, созданный Стеком ИИ, в запросах на вытягивание](/ru/copilot/tutorials/stack-ai-generated-code-in-pull-requests).\n\n## 5. Обновление программного средства\n\nЧтобы обеспечить внедрение, просмотрите все встроенные средства, боты или панели мониторинга, которые создают, объединяют или отслеживают запросы на вытягивание программными средствами и обновляют их для учета стека.\n\nЕсли ваша организация предоставляет внутренний интерфейс командной строки или другое средство разработчика, вы можете использовать API Stacks для интеграции создания стека и управления ими в существующие средства, а не требовать от разработчиков внедрения `gh stack`.\n\n> \\[!IMPORTANT]\n> Для объединения запроса на вытягивание с накоплением требуется API асинхронного слияния. Устаревшие конечные точки слияния запросов на вытягивание не могут объединить стек. Если организация объединяет запросы на вытягивание программным способом, например с помощью встроенных инструментов или ботов ChatOps, обновите это средство для вызова API асинхронного слияния, который поддерживает как стек, так и обычные запросы на вытягивание, прежде чем развертывать стекированные запросы на вытягивание. См [. раздел AUTOTITLE](/ru/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).\n\nВы также можете программно отслеживать действия стека, например на панелях мониторинга, ботах или внутренних инструментах.\n\n* **REST API**: каждый запрос на вытягивание, возвращаемый API, включает `stack` объект, когда он принадлежит стеку, показывающий число, размер, положение запроса на вытягивание внутри него и базовую ветвь стека. Выделенный API стека (`GET /repos/{owner}/{repo}/stacks`) также перечисляет каждый стек в репозитории или конкретный стек, содержащий заданный запрос на вытягивание. См [. раздел AUTOTITLE](/ru/pull-requests/reference/stacked-pull-requests-apis-and-webhooks).\n* **Веб-перехватчики**: `pull_request` полезные данные веб-перехватчика включают тот же `stack` объект, когда запрос на вытягивание принадлежит стеку.\n  `stacked` Выделенное действие запускается при первом добавлении запроса на вытягивание в стек, чтобы вы могли реагировать на момент форм стека.\n\nВ обоих случаях `stack` поле предназначено `null` для автономных запросов на вытягивание, поэтому существующие интеграции, которые не ожидают, что стеки продолжают работать без изменений."}