Примечание.
Эта функция доступна в публичном предварительном просмотре и может измениться.
Сведения о запросах на вытягивание с накоплением
Запросы на вытягивание с накоплением — это два или более запросов на вытягивание в одном репозитории, где:
- Первый или нижний запрос на вытягивание предназначен для магистрали стека — обычно ветвь по умолчанию репозитория, например
main, хотя это может быть любая ветвь, например ветвь выпуска. - Каждый последующий запрос на вытягивание предназначен для ветви запроса на вытягивание под ним.
┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top
┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
┌── feat/auth-layer → PR #1 (base: main) ← bottom
main (default base branch)
Ветви стека образуют цепочку зависимостей, где каждая ветвь строится на одной из них. Базовые изменения, такие как общие типы и схема базы данных, идут в более низких ветвях и код, который зависит от них, например маршруты API и компоненты пользовательского интерфейса, переходят в более высокие ветви.
Каждый запрос на вытягивание в стеке представляет собой дискретное, проверяемое изменение одной или нескольких фиксаций. Вы можете просмотреть и выполнить итерацию по каждому запросу на вытягивание независимо, и каждый из них показывает только дифф для своего слоя и изменения между его ветвью и ветвью под ним.
Ключевой принцип: если код в одном слое зависит от кода в другом, зависимость должна находиться в той же ветви или нижней. Создайте новую ветвь при запуске другой проблемы, которая зависит от того, что вы создали до сих пор. Например, при переходе с серверной части на интерфейсную работу, переход от основной логики к тестам или когда текущая ветвь уже достаточно велика для проверки.
Почему используйте GitHub запросы на вытягивание с накоплением
Завершите одно изменение и перейдите прямо на следующий
Запросы на вытягивание с накоплением позволяют открывать новый запрос на вытягивание поверх открытого. Во время большого проекта следующее изменение может зависеть от работы, которая еще не объединена. Вместо того, чтобы дождаться слияния, стеком можно сохранить сборку.
При каждом запросе на вытягивание в стеке, содержающем одно фокусное изменение, рецензенты видят небольшой дифф для каждого слоя вместо большого запроса на вытягивание. Более мелкие запросы на вытягивание быстрее просматриваются, менее вероятно, будут пропущены, и менее вероятно, что они устаревают и развивают конфликты слиянием.
Подходит для разработки больших объемов
При создании большого количества кода одновременно часто с агентами ИИ стек дает каждому изменению место для перехода. Агент завершает одну задачу, а затем запускает следующую задачу, которая строится на ней. Эта последовательность сопоставляется непосредственно с стеком: один запрос на вытягивание для каждой задачи, каждый из которых основан на приведенном ниже. Стеки позволяют записывать эти зависимости явно вместо объединения несвязанных изменений в одну ветвь.
Преимущества использования запросов на вытягивание с накоплением в GitHub
Без стека запросов на вытягивание, нарушение большого изменения в меньший, зависимые запросы на вытягивание создают дополнительную работу:
- Управление филиалами. Повторное масштабирование и сохранение ветвей в синхронизации между зависимыми запросами на вытягивание является емким и подверженным ошибкам.
- Правила и CI. Правила защиты ветви и проверки CI часто активируются только для нижнего запроса на вытягивание в цепочке, что делает его трудно знать истинное состояние остальных.
- Просмотрите контекст. Проверка единого изменения контекста из остальной части стека может снизить качество проверки.
Запросы на вытягивание с накоплением устраняют эти проблемы, рассматривая цепочку запросов на вытягивание как подключенную единицу, сохраняя каждый слой небольшим и ориентированным.
Перебазирование
Перебазирование является самой сложной частью работы с стеками и GitHub обрабатывает ее автоматически. Вы можете активировать каскадную базу на стороне сервера из запроса на вытягивание или выполнить локальную каскадную перебазу с расширениемgh stack.GitHub CLI При слиянии запроса на вытягивание в нижней части стека остальные ветви автоматически перебазируются, поэтому следующий запрос на вытягивание предназначен для базовой ветви по умолчанию.
Где можно использовать запросы на вытягивание с накоплением
Запросы на вытягивание с накоплением доступны в следующих случаях:
- GitHub CLI
- GitHub Веб-сайт
- GitHub Mobile
- Программная поддержка с помощью веб-перехватчиков, REST API и GraphQL
- Для агентов с помощью навыка
gh-stack
Примечание.
- Запросы на вытягивание с накоплением требуют наличия всех ветвей в одном репозитории. Кросс-форковые стеки не поддерживаются.
- Запросы на вытягивание с накоплением не поддерживаются GitHub Desktop.
В GitHub CLI
Расширение gh stack обрабатывает GitHub CLI локальный рабочий процесс разработки. Вы можете создавать и отслеживать ветви в правильном порядке зависимостей, сохранять ветви повторно базироваться, отправлять ветви, создавать и связывать запросы на вытягивание и перемещаться между слоями. См . раздел AUTOTITLE.
GitHub На веб-сайте
Когда запрос на вытягивание является частью стека, вы увидите:
- Значок стека в верхней части запроса на вытягивание с номером, указывающим, какой слой вы просматриваете.
- Карта стека отображается в поле слияния. Он отображает каждый запрос на вытягивание в стеке и его состоянии, а также позволяет перейти к любому уровню с одним щелчком мыши. Магистраль (базовая ветвь по умолчанию) находится внизу с каждым запросом на вытягивание в стеке, предназначенным для ветви запроса на вытягивание под ним.
Программная поддержка с помощью веб-перехватчиков, REST API и GraphQL
Запросы на вытягивание с накоплением доступны программным способом, поэтому их можно интегрировать в собственные средства, автоматизацию и панели мониторинга:
- Веб-перехватчики включают
stackобъект вpull_requestполезные данные событий, поэтому автоматизация может реагировать, когда запрос на вытягивание присоединяется, перемещается внутри или оставляет стек. - REST API считывает членство в стеке запроса на вытягивание и предоставляет конечные точки для перечисления, создания, расширения и растворения стека.
- API GraphQL предоставляет поля только
stackдля чтения в запросе на вытягивание для запроса стека и положения запроса на вытягивание в нем.
Правила, CI и объединение
Правила и принудительное применение CI
Запросы на вытягивание с накоплением поддерживают GitHub Actions рабочие процессы.
Требования к слиянию для любого запроса на вытягивание в стеке определяются базовой ветвью нижнего запроса на вытягивание, как правило main.
- Правила защиты ветви, такие как утверждения CODEOWNER, применяются к каждому запросу на вытягивание в стеке, даже в середине стека запросов на вытягивание, которые не нацелены непосредственно на ветвь по умолчанию.
- Проверки CI, активированные запросами на вытягивание в ветви по умолчанию, выполняются для всех запросов на вытягивание в стеке, а не только нижнего.
Это гарантирует, что каждый слой стека соответствует той же панели качества, прежде чем она сможет объединиться.
Объединение
Вы можете объединить весь стек, один запрос на вытягивание или часть стека, охватывающего несколько запросов на вытягивание. Весь стек не должен объединяться одновременно, но запросы на вытягивание должны объединяться снизу вверх.
- Объедините весь стек одновременно, объединив верхний запрос на вытягивание. Каждый запрос на вытягивание под ним поставляется.
- Объединение части стека путем объединения запроса на вытягивание среднего стека. Запросы на вытягивание под ним также объединяются, и указанные выше запросы на вытягивание остаются открытыми и автоматически перенацеливают базовую ветвь стека.
Стеки поддерживают фиксацию слиянием, сквош и методы слияния повторной базы данных, а также поддерживаются с учетом очереди слиянием. Результирующий журнал фиксации совпадает с объединением каждого запроса на вытягивание по отдельности, начиная с нижней части.
Примечание.
Если вы объединяетесь через API и хотите использовать стековые запросы на вытягивание, необходимо обновить, чтобы использовать новый API слияния для стеков. См . раздел AUTOTITLE.