GitHub flow
GitHub flow держит ОДНУ долгоживущую ветку — main, всегда деплоибельную — плюс короткоживущие фичеветки: открыть pull request, пройти CI и ревью, слить, задеплоить. Нет develop и релизных веток. Быстр для веба на CD, но требует сильный CI, быстрое ревью и feature-флаги.
Возьми git-flow, удали develop, удали release-ветки, удали всю церемонию версионирования и оставь одно правило: main всегда деплоибельна. Останется GitHub flow — workflow, который реально применяет большинство малых и средних продуктовых команд, и тот, на котором GitHub построил собственный продукт. У него ровно одна долгоживущая ветка и один тип короткоживущих веток, и он подходит миру, где «релиз» означает просто «слить и задеплоить».
К концу этого урока ты сможешь проследить изменение сквозь однобраночную модель GitHub flow, назвать три вещи, которые он тихо предполагает о твоей команде, и точно сказать, чем он отличается от только что изученного git-flow.
После этого урока ты сможешь описать модель GitHub flow с одной долгоживущей веткой, проследить изменение от фичеветки через pull request до деплоя и назвать три предусловия — сильный CI, быстрое ревью и feature-флаги, — которые делают его безопасным.
Существует ровно одна долгоживущая ветка — main — и она всегда деплоибельна. Это единственное правило, на котором держится всё остальное. Каждый коммит на main по определению — это то, что ты мог бы отгрузить в продакшен прямо сейчас. Нет develop, нет интеграционной ветки, нет «кода, который готов, но ещё не выпущен» — готово значит выпущено. Задача всего workflow — защитить этот инвариант: ничто не достигает main, пока оно не отревьюено, не прошло CI и не безопасно для деплоя.
Вся работа происходит на короткоживущих фичеветках, названных по намерению. Когда ты начинаешь что угодно — фичу, правку, эксперимент — ты ответвляешься от main:
git checkout main
git pull
git checkout -b add-csv-export
# ... коммиты ...
git push -u origin add-csv-exportЭти ветки живут часы или день-два, а не недели. Имя ветки описывает изменение (add-csv-export, fix-login-redirect), и ветка существует ровно столько, чтобы изменение отревьюили и слили. Держать её короткой — это то, что не даёт ей далеко уйти от main и вызвать ад слияний, который порождают длинные ветки.
Pull request — это место, где происходят ревью, CI и обсуждение до слияния. Запушив ветку, ты открываешь pull request (PR) — запрос на слияние твоей ветки в main. PR — контрольная точка workflow: автоматический CI прогоняет тестовый набор, коллеги ревьюят дифф, а обсуждение изменения записывается рядом с ним. На защищённой main платформа отказывает в слиянии, пока обязательные проверки не пройдут и ревью не одобрено. PR — это весь контроль качества GitHub flow: позже нет релизной ветки, которая поймает проблемы, поэтому всё должно быть поймано здесь.
Слияние в main запускает деплой; затем ветка удаляется. Как только PR одобрен и зелёный, ты сливаешь его в main. Поскольку main всегда деплоибельна, это слияние и есть релиз — большинство команд подключают непрерывный деплой, так что слияние автоматически отгружает в продакшен:
# после одобрения слить через PR (squash или merge-коммит), затем:
git checkout main
git pull
git branch -d add-csv-exportНет шага «тег и стабилизация», нет слияния обратно в develop. Слил, задеплоил, удалил ветку, пошёл дальше. Простота — это и есть суть: от идеи до продакшена — одна ветка и одно слияние.
▸Почему это работает
А что с работой, которая не закончена, но ты всё равно хочешь её слить, чтобы ветка осталась короткой? Ответ GitHub flow — feature-флаг: слей незавершённый код в main за рантайм-переключателем, который выключен в продакшене. Код отгружается (то есть он интегрирован и протестирован против чужой работы), но остаётся невидимым для пользователей, пока флаг не включат. Так GitHub flow держит ветки короткими и избегает отгрузки наполовину готовых фич — незавершённость живёт во флаге, а не в долгоживущей ветке. Это же и мост к trunk-based development в следующем уроке.
Отгрузка CSV-экспорта во вторник.
Во вторник утром ты ответвляешь add-csv-export от свежей main. Пишешь экспорт плюс тесты, пушишь и к обеду открываешь PR. CI прогоняет набор (зелёный), а коллега ревьюит дифф, просит один переименовать, ты пушишь правку. В середине дня PR одобрен и зелёный; ты сливаешь. Твой CD-конвейер подхватывает слияние в main и деплоит в продакшен за минуты. Ты удаляешь ветку. Фича была идеей в 9 утра и живой к 15:00, и ни в один момент main не содержала ничего недеплоибельного.
Сравни с git-flow: там то же изменение слилось бы в develop, ждало бы нарезки и стабилизации ветки release/1.x, потом слилось бы в main и было бы помечено тегом перед деплоем — дни, а не часы. GitHub flow меняет версионную мощь git-flow на чистую скорость, что ровно правильный обмен для веб-приложения, у которого версий нет вовсе.
▸Частая ошибка
GitHub flow выглядит беспроблемным, но он тихо предполагает три вещи, и убери любую — он станет опасным. Сильный CI: без релизной ветки, которая ловит баги, автотесты PR — твоя единственная страховочная сеть, так что они должны быть тщательными и надёжными. Быстрое ревью: короткие ветки остаются короткими, только если PR ревьюят за часы, а не за дни — медленное ревью тихо превращает GitHub flow в ад долгоживущих веток. Feature-флаги: без них «всегда деплоибельная main» вынуждает тебя либо держать большие фичи на длинной ветке (рушит модель), либо отгружать их недоделанными. Команды, которые перенимают структуру веток GitHub flow, но пропускают эти три предусловия, получают простоту на бумаге и хаос на практике.
В чём определяющее структурное различие между GitHub flow и git-flow?
GitHub flow держит ровно одну долгоживущую ветку — main, всегда деплоибельную — плюс короткоживущие фичеветки, которые открывают pull request, проходят CI и ревью, сливаются и деплоятся. Нет develop и нет релизной ветки; готово значит выпущено. Он проще и намного быстрее git-flow, что делает его дефолтом для веб-приложений на непрерывном деплое и workflow, который применяет большинство малых и средних продуктовых команд. Но он предполагает сильный CI, быстрое ревью и feature-флаги для незавершённой работы — убери любое, и простота рушится. Дальше ты увидишь, как высокоскоростные организации толкают эту идею ещё дальше с trunk-based development.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.