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

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

В этом руководстве описано, как подготовить организацию к запросам на вытягивание с накоплением: просмотр рекомендаций по развертыванию, понимание того, как правила защиты филиалов и CI работают с стеками, и приступить к работе с командами. Основные сведения о запросах на вытягивание с накоплением см. в разделе Сведения о запросах на вытягивание с накоплением.

Необходимые условия

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

• GitHub CLIс установленным расширением gh-stack . Расширение CLI — это самый полный способ создания стека и управления ими.
• Правила защиты ветви, настроенные для ветви по умолчанию.
• GitHub Actions рабочие процессы, выполняемые при запросах на вытягивание, предназначенные для ветви по умолчанию.

Copilot не требуется использовать запросы на вытягивание с накоплением, но рекомендуется для команд, которые хотят стекировать изменения, созданные ИИ. Запросы на вытягивание с накоплением также работают с другими агентами программирования ИИ, такими как Claude Code и Codex, используя предоставленный навык агента. См . раздел AUTOTITLE.

1. Обзор рекомендаций по развертываниям

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

Стеки должны быть линейными и не могут включать в себя вилки

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

Для переупорядочения стека требуется GitHub CLI

Если команде необходимо изменить порядок запросов на вытягивание в стеке, им потребуется использовать gh stack modify в gh stackGitHub CLI расширении. Нет способа переупорядочения стека с GitHub веб-сайта. Команды, которые не используют интерфейс командной строки локально, должны тщательно спланировать порядок стека или установить расширение для этой задачи.

Завершенный стек не может быть расширен

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

2. Узнайте, как правила защиты ветви и CI работают с стеками

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

Каждый запрос на вытягивание в стеке, а не только нижний, оценивается по базе стека (как правило main), а не по ветвью, на который он непосредственно нацелен. Это означает:

• Обязательные проверки, необходимые проверки состояния и CODEOWNERS применяются к базовой ветви стека для каждого запроса на вытягивание в стеке.
• Рабочий GitHub Actions процесс, который активирует pull_request события, предназначенные main для каждого запроса на вытягивание в стеке, поэтому существующая конфигурация CI не требует изменения.
• Метаданные стека доступны в выражениях рабочих github.event.pull_request.stackпроцессов, если вы хотите настроить поведение рабочего процесса специально для запросов на вытягивание с накоплением. Так как рабочий процесс выполняется один раз на запрос на вытягивание в стеке, команды могут использовать эти метаданные для пропуска дорогостоящих заданий при избыточных запусках и уменьшении использования CI. Дополнительные сведения см. в разделе Оптимизация CI для запросов на вытягивание с накоплением.

При необходимости вы можете увидеть это в действии, открыв небольшой стек тестов для репозитория со стандартными наборами правил и обязательными проверками, и убедив, что:

1. Проверки и проверки состояния требуются для каждого запроса на вытягивание в стеке, а не только нижнего.
2. Рабочие процессы CI выполняются при каждом запросе на вытягивание в стеке.
3. Слияние блокируется до тех пор, пока запрос на вытягивание в стеке, который вы хотите объединить, и все, что находится под ним, соответствует вашим требованиям.

Полный список правил и требований см. в разделе Запросы на вытягивание с накоплением.

3. Начало работы команд

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

4. Обновление программного инструмента

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

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

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

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