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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы создать свой первый стек, направляйте пользователей в Краткое руководство по запросам на вытягивание с накоплением. После пилотного проекта соберите отзывы от разработчиков и рецензентов:

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

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

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

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

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

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

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

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

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

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

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