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

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

Каждый запрос на вытягивание в стеке вычисляется по правилам для базы стека , как правило main , независимо от того, какая ветвь она непосредственно предназначена. Это означает, что запросы на вытягивание в середине стека хранятся в том же стандарте, что и нижний запрос на вытягивание.

Доступность запросов на вытягивание с накоплением

Расширение gh stackGitHub CLI обрабатывает локальный рабочий процесс разработки. Он создает и отслеживает ветви в правильном порядке зависимостей, сохраняет ветви перебазироваться, отправляет ветви, создает и связывает запросы на вытягивание и перемещается между слоями.

GitHub CLI не требуется. Базовые операции Git являются стандартными, и вместо этого можно создавать стеки с GitHub веб-сайта.

Если вы используете другие средства, такие как Jujutsu или Sapling, для управления и отправки локальных ветвей, вы по-прежнему можете использовать GitHub CLI или GitHub веб-сайт, чтобы открыть стек запросов на вытягивание из этих ветвей. См . раздел AUTOTITLE.

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

Магистраль стека — это базовая ветвь нижнего запроса на вытягивание. Каждый другой запрос на вытягивание в стеке построен на его основе. Магистраль по умолчанию используется в ветви по умолчанию репозитория, например mainв любой ветви, например ветвь выпуска или ветвь функции длительного времени.

Чтобы задать магистраль, выполните следующие действия.

• От GitHub CLI--base BRANCH передайте параметр в gh stack init команду (например, gh stack init --base release auth-layer).
• GitHub На веб-сайте создайте запрос на вытягивание нижней части в любой ветви, которую вы хотите использовать в качестве магистрали. Остальная часть стека строится поверх нее.

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

Защита ветви и обязательные проверки

Ниже приведены все оценки, как если бы каждый запрос на вытягивание предназначен для базы стека, а не ветви непосредственно под ним:

Правило	Как она оценивается
Обязательные проверки	Вычисляется по базе стека.
Обязательные статусные проверки	Вычисляется по базе стека.
Ответственные за код (CODEOWNERS)	Вычисляется из базы стека.
CODEOWNERS Изменения в более низком запросе на вытягивание, но не влияют на запросы на вытягивание над ним.
Рабочие процессы сканирования кода	Вычисляется по базе стека.

GitHub Actions

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

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

Полный набор полей метаданных и шаблонов для уменьшения избыточного использования CI см. в разделе Оптимизация CI для запросов на вытягивание с накоплением.

Требования к слиянию

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

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

Например, в стеке main ← PR1 ← PR2 ← PR3слияние PR #3 требуется PR #1 и PR #2 для прохождения проверок, наличие необходимых проверок и соответствие всем правилам защиты ветви.

Методы слияния

Стеки поддерживают все три метода слияния. В каждом случае запросы на вытягивание выполняются в виде одной атомарной операции:

• Фиксация слияния создает одну фиксацию слияния для всей группы запросов на вытягивание, сохраняя полный журнал фиксации каждого запроса на вытягивание.
• Squash создает одну чистую, сквашированную фиксацию на запрос на вытягивание. Объединение n запросов на вытягивание создает n сквашированные фиксации в базовой ветви.
• Перебазирует фиксации из каждого запроса на вытягивание в базовую ветвь, создавая линейную историю без фиксаций слияния.

Слияние с помощью очереди слияния

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

Линейная история

Полностью линейная история между каждой ветвью в стеке является строгим требованием для объединения. Стек может потерять линейную историю, когда изменения отправляются в нижнюю ветвь или когда магистраль движется вперед.

Чтобы восстановить линейную историю, выполните каскадную перебазу:

• Из интерфейса командной строки — запустите gh stack rebase, а затем отправьте с gh stack pushпомощью.
• GitHub На веб-сайте щелкните стек перебазы в поле слияния, чтобы активировать каскадную базу на стороне сервера.

Инструкции см. в разделе Управление запросами на вытягивание с накоплением.

Дополнительные материалы

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