Очереди слияния и зелёный main

Почему зелёные PR всё равно ломают main

Если ты хоть раз видел, как два зелёных PR ломают main на строке, которую никто не трогал, — это ровно тот сбой. За десять минут поймёшь механизм, почему очевидные фиксы не работают и что merge queue (очередь слияния) реально с этим делает.

Обязательная проверка на pull request не тестирует main. Она тестирует голову твоего PR, слитую с main таким, каким он был в момент запуска CI, — снимок. К моменту, когда твой PR действительно сливается, другие PR могли приземлиться впереди него, так что main, против которого валидировался твой код, больше не существует.

Слияние git блокирует только текстовые конфликты: два изменения пересекающихся строк. Оно полностью слепо к логическим (семантическим) конфликтам, где два изменения не делят ни единой строки, но несовместимы по смыслу:

PR A (зелёный):  rename computeShippingCost -> shippingCost, обновить 11 вызовов
PR B (зелёный):  добавить НОВЫЙ вызов computeShippingCost(...) в файле, который PR A не трогал
                 (отведён до того, как PR A существовал)

git merge A затем B:  ноль пересекающихся строк  ->  сливается чисто
результат в main:     вызов функции, которой больше нет  ->  сборка красная

Каждый PR был зелёным против того main, на котором тестировался. Ни один прогон тестов не мог поймать поломку, потому что комбинация — A и B вместе — это состояние, которого нигде не существовало, пока слияние его не создало. Вот почему «просто перезапусти проверки на каждом PR» не спасает: перезапуск всё ещё тестирует каждый PR против main, который устаревает в тот же миг, как приземляется другой PR. Чем выше скорость слияния, тем чаще «протестировано против main, которого больше нет» выкатывает сломанный main.

Merge queue: тестировать main-каким-он-станет

Merge queue (очередь слияния; реализации — GitHub merge queue, Bors, Mergify) чинит это, сериализуя интеграцию. Вместо того чтобы слить PR напрямую, она конструирует спекулятивную ветку (временную ветку «как будто всё уже слито») = текущий main + этот PR (плюс всё, что впереди него в очереди) и прогоняет полный набор обязательных проверок на этом комбинированном результате. PR приземляется только если сборка очереди — main ровно такой, каким он станет после слияния этого батча, — зелёная.

# GitHub merge queue: обязательная проверка запускается на событии merge_group,
# то есть против спекулятивной ветки, которую строит очередь (main + очередь PR),
# А НЕ просто против головы PR. main защищён; ничто не пушит напрямую.
on:
  merge_group:        # <- спекулятивная сборка очереди
  pull_request:       # <- всё ещё на каждый PR ради быстрого фидбэка автору
jobs:
  required-checks:
    runs-on: ubuntu-latest
    steps:
      - run: ./ci/affected-build-and-test.sh   # держи БЫСТРОЙ — она гейтит очередь

Ничто не достигает main, не протестированное против ровно тех других изменений, что приземляются вместе с ним. PR с ренеймингом и PR с новым вызовом, поставленные в очередь вместе, были бы собраны на одной спекулятивной ветке — и эта сборка падает до того, как любой из них сольётся, так что виновник удерживается вне, а не отравляет всех. main остаётся зелёным не благодаря удаче или бдительности, а по построению: единственное, что вообще приземляется, — это комбинация, уже доказанно зелёная как комбинация.

Батчинг и бисекция: пропускная способность при высоком объёме слияний

Тестировать по одному PR за раз против текущего main корректно, но медленно: при высоком объёме очередь становится строем в один ряд, и каждый прогон CI пропускает только один PR. Поэтому очереди батчат — спекулятивно собирают main + PR1 + PR2 + … + PRn вместе. Если батч зелёный, все n PR сливаются с одного прогона CI. В этом выигрыш пропускной способности: одна дорогая сборка пропускает весь батч вместо n сборок, пропускающих n PR.

Риск в том, что один плохой PR в батче красит весь батч. Очередь справляется с этим, бисектя (bisect — делением пополам для локализации виновника): она разбивает падающий батч, чтобы найти, какой PR виноват, выгоняет виновника (отбрасывает обратно его автору) и перезапускает оставшиеся PR меньшим батчем. Так один сломанный PR удаляет себя сам, а не блокирует четыре хороших PR, стоящих вокруг него в очереди.

# Батч из 4 собран спекулятивно вместе; сборка батча падает.
# Очередь бисектит, локализуя поломку, выгоняет виновника, перезапускает остальных.
queue batch: [PR1, PR2, PR3, PR4]   -> спекулятивная сборка КРАСНАЯ
  bisect [PR1, PR2] -> зелёный       # поломка во второй половине
  bisect [PR3, PR4] -> красный       # сужено
  bisect [PR3]      -> зелёный
  bisect [PR4]      -> красный        # PR4 — виновник
eject PR4 (обратно автору); re-run [PR1, PR2, PR3] -> зелёный -> слить 3

Компромисс прямой: больше батчи = выше пропускная способность, но больше потерянной работы при падении (красный батч из 8 выбрасывает сборку восьмёрки и запускает бисекцию). Меньшие батчи переделывают меньше, но пропускают меньше PR за прогон. Размер батча ты настраиваешь под свою частоту падений — флакающий или склонный к поломкам репозиторий хочет меньших батчей; дисциплинированный с редкими падениями может гонять большие батчи и редко платить налог бисекции.

Почему очереди нужны защита ветки и быстрый гейт

Без этих двух предусловий гарантия очереди испаряется. Когда настраиваешь merge queue, спроси себя: есть ли путь в main, обходящий очередь, и достаточно ли быстра гейтящая проверка, чтобы не дросселировать команду?

Merge queue работает только если main защищён — никаких прямых пушей — и комбинированная проверка очереди является обязательным гейтом. Если кто угодно может пушить в main напрямую, он обходит спекулятивную сборку, и вся гарантия испаряется: очередь может обещать «всё, что приземлилось, было доказано зелёным как комбинация» только если всё приземляется через очередь.

И гейт должен быть быстрым. Пропускная способность очереди ограничена длительностью гейтящей проверки: очередь не может пропустить PR2, пока не закончится сборка, включающая PR1, так что 40-минутная обязательная проверка ограничивает твою скорость слияния независимо от того, сколько PR ждёт. Это сквозная линия всего этого юнита — сборки только затронутого, кэширование, шардинг тестов, правильно подобранные раннеры существуют, чтобы обязательная проверка оставалась короткой, потому что здесь именно эта проверка дросселирует каждое слияние в организации. Медленный гейт не просто раздражает одного автора; он сериализует всю команду за собой.