{"meta":{"title":"Запросы на вытягивание с накоплением","intro":"Правила и требования для работы с GitHubзапросами на вытягивание с накоплением.","product":"Запросы на включение внесенных изменений","breadcrumbs":[{"href":"/ru/pull-requests","title":"Запросы на включение внесенных изменений"},{"href":"/ru/pull-requests/reference","title":"Справочные материалы"},{"href":"/ru/pull-requests/reference/stacked-pull-requests","title":"Запросы на вытягивание с накоплением"}],"documentType":"article"},"body":"# Запросы на вытягивание с накоплением\n\nПравила и требования для работы с GitHubзапросами на вытягивание с накоплением.\n\n> \\[!NOTE] Эта функция доступна в публичном предварительном просмотре и может измениться.\n\nСтек — это ряд запросов на вытягивание в том же репозитории, где каждый запрос на вытягивание предназначен для ветви запроса на вытягивание под ним, формируя упорядоченную цепочку, которая приземляется в одной ветви, как правило, ваша основная ветвь. Вместо одного большого запроса на вытягивание вы получаете набор небольших запросов на вытягивание. Так как каждый запрос на вытягивание имеет свой собственный фокус, товарищи по команде могут просматривать и утверждать каждый слой независимо.\n\nКаждый запрос на вытягивание в стеке вычисляется по правилам для **базы стека** , как правило `main` , независимо от того, какая ветвь она непосредственно предназначена. Это означает, что запросы на вытягивание в середине стека хранятся в том же стандарте, что и нижний запрос на вытягивание.\n\n> \\[!NOTE]\n>\n> * Запросы на вытягивание с накоплением требуют наличия всех ветвей в одном репозитории. Кросс-форковые стеки не поддерживаются.\n> * Запросы на вытягивание с накоплением не поддерживаются GitHub Desktop.\n\n## Доступность запросов на вытягивание с накоплением\n\nРасширение `gh stack`GitHub CLI обрабатывает локальный рабочий процесс разработки. Он создает и отслеживает ветви в правильном порядке зависимостей, сохраняет ветви перебазироваться, отправляет ветви, создает и связывает запросы на вытягивание и перемещается между слоями.\n\nGitHub CLI не требуется. Базовые операции Git являются стандартными, и вместо этого можно создавать стеки с GitHub веб-сайта.\n\nЕсли вы используете другие средства, такие как Jujutsu или Sapling, для управления и отправки локальных ветвей, вы по-прежнему можете использовать GitHub CLI или GitHub веб-сайт, чтобы открыть стек запросов на вытягивание из этих ветвей. См [. раздел AUTOTITLE](/ru/pull-requests/reference/use-other-tools-with-stacked-pull-requests).\n\n## Магистрали для запросов на вытягивание с накоплением\n\n**Магистраль** стека — это базовая ветвь нижнего запроса на вытягивание. Каждый другой запрос на вытягивание в стеке построен на его основе. Магистраль по умолчанию используется в ветви по умолчанию репозитория, например `main`в любой ветви, например ветвь выпуска или ветвь функции длительного времени.\n\nЧтобы задать магистраль, выполните следующие действия.\n\n* **От GitHub CLI**`--base BRANCH` передайте параметр в `gh stack init` команду (например, `gh stack init --base release auth-layer`).\n* **GitHub На веб-сайте** создайте запрос на вытягивание нижней части в любой ветви, которую вы хотите использовать в качестве магистрали. Остальная часть стека строится поверх нее.\n\nПравила защиты филиалов, обязательные проверки и CI оцениваются независимо от целевого объекта стека, а не только в вашей ветви по умолчанию.\n\n## Защита ветви и обязательные проверки\n\nНиже приведены все оценки, как если бы каждый запрос на вытягивание предназначен для базы стека, а не ветви непосредственно под ним:\n\n| Правило                                                                                                       | Как она оценивается        |\n| ------------------------------------------------------------------------------------------------------------- | -------------------------- |\n| Обязательные проверки                                                                                         | Вычисляется по базе стека. |\n| Обязательные статусные проверки                                                                               | Вычисляется по базе стека. |\n| Ответственные за код (CODEOWNERS)                                                                             | Вычисляется из базы стека. |\n| `CODEOWNERS` Изменения в более низком запросе на вытягивание, но не влияют на запросы на вытягивание над ним. |                            |\n| Рабочие процессы сканирования кода                                                                            | Вычисляется по базе стека. |\n\n## GitHub Actions\n\nGitHub Рабочие процессы действий активируются так, как если бы каждый запрос на вытягивание в стеке предназначен для базы стека. Рабочий процесс, настроенный для запуска событий `pull_request` , предназначенных `main` для **каждого** запроса на вытягивание в стеке, а не только нижнего, поэтому изменения рабочего процесса не требуются.\n\nМетаданные стека, такие как базовая ветвь стека, доступны в выражениях рабочих процессов с помощью `github.event.pull_request.stack`. Это свойство присутствует только в том случае, если запрос на вытягивание принадлежит стеку.\n\nПолный набор полей метаданных и шаблонов для уменьшения избыточного использования CI см. в разделе [Оптимизация CI для запросов на вытягивание с накоплением](/ru/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).\n\n## Требования к слиянию\n\nПрежде чем запрос на вытягивание в стеке может объединиться, все из следующих элементов должны быть верными:\n\n* Запрос на вытягивание соответствует каждому требованию защиты ветви для базы стека, включая необходимые проверки, необходимые проверки состояния и утверждения CODEOWNER.\n* **Все запросы на вытягивание под ним** в стеке также соответствуют этим требованиям.\n* Стек имеет **полностью линейную историю** между ветвями.\n\nНапример, в стеке `main ← PR1 ← PR2 ← PR3`слияние PR #3 требуется PR #1 и PR #2 для прохождения проверок, наличие необходимых проверок и соответствие всем правилам защиты ветви.\n\n## Методы слияния\n\nСтеки поддерживают все три метода слияния. В каждом случае запросы на вытягивание выполняются в виде одной атомарной операции:\n\n* **Фиксация** слияния создает одну фиксацию слияния для всей группы запросов на вытягивание, сохраняя полный журнал фиксации каждого запроса на вытягивание.\n* **Squash** создает одну чистую, сквашированную фиксацию на запрос на вытягивание. Объединение `n` запросов на вытягивание создает `n` сквашированные фиксации в базовой ветви.\n* **Перебазирует** фиксации из каждого запроса на вытягивание в базовую ветвь, создавая линейную историю без фиксаций слияния.\n\n## Слияние с помощью очереди слияния\n\nСтеки полностью поддерживают очереди слиянием. Все запросы на вытягивание в стеке добавляются в очередь в правильном порядке. Если запрос на вытягивание удаляется или удаляется из очереди, все запросы на вытягивание над ним в стеке также удаляются.\n\n> \\[!NOTE]\n> Чтобы сохранить стек вместе, очередь слияния позволяет группе слияний превышать заданный максимальный размер до 50 процентов. Если стек слишком велик, чтобы поместиться в этот буфер, он автоматически будет разделен между последовательными группами слиянием.\n\n## Линейная история\n\nПолностью линейная история между каждой ветвью в стеке является строгим требованием для объединения. Стек может потерять линейную историю, когда изменения отправляются в нижнюю ветвь или когда магистраль движется вперед.\n\nЧтобы восстановить линейную историю, выполните каскадную перебазу:\n\n* **Из интерфейса командной строки** — запустите `gh stack rebase`, а затем отправьте с `gh stack push`помощью.\n* **GitHub На веб-сайте** щелкните **стек перебазы** в поле слияния, чтобы активировать каскадную базу на стороне сервера.\n\nИнструкции см. в разделе [Управление запросами на вытягивание с накоплением](/ru/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#rebasing-your-stack).\n\n## Дополнительные материалы\n\n* [Развертывание запросов на вытягивание с накоплением в организации](/ru/pull-requests/tutorials/roll-out-stacked-prs)"}