Зачем нужен workflow ветвления?
Workflow ветвления — это контракт команды о том, как код идёт от идеи в продакшен: какие ветки есть, что защищено, как делаются релизы и хотфиксы. Четыре оси — число веток, время жизни ветки, частота релизов и момент интеграции — разделяют три модели реальных команд.
Пять инженеров, один репозиторий и никакого согласия о том, как работают ветки. Двое пушат прямо в main; один держит трёхнедельную фичеветку, которая молча разошлась со всеми остальными; никто не знает, какой коммит сейчас в продакшене, а хотфикс для платящего клиента только что случайно уехал вместе с наполовину готовым редизайном. Ничего из этого не баг git. Это отсутствие workflow — общего правила о том, как код движется от идеи в продакшен.
К концу этого урока ты сможешь сказать, что именно решает за команду workflow ветвления, и назвать четыре оси, которые разделяют три модели — git-flow, GitHub flow и trunk-based development, — сравниваемые в остатке этого юнита лоб в лоб.
После этого урока ты сможешь определить workflow ветвления как командный контракт, перечислить четыре оси, которые различают workflow (число долгоживущих веток, время жизни ветки, частота релизов, момент интеграции), и объяснить режимы отказа, которые возникают, когда у команды нет workflow вовсе.
Workflow ветвления — это согласованный командой контракт о том, как код едет от идеи в продакшен. Он отвечает на фиксированный набор вопросов одинаково для всех: какие ветки существуют всегда, какая ветка — источник истины, кому куда можно пушить, как изменение проходит ревью и интегрируется, как нарезается релиз и как срочный продакшен-фикс обходит обычный путь. Сам git не имеет мнения — он даёт дешёвые ветки и слияния и молчит о том, как ими пользоваться. Workflow — это слой политики, который команда добавляет сверху, чтобы два инженера в два разных дня приняли одно и то же структурное решение без совещания.
Без workflow ты получаешь четыре повторяющихся режима отказа. Они достаточно предсказуемы, чтобы их назвать:
- Нет точки релиза. Если все коммитят в
mainкак попало, никто не ответит «что в продакшене?», потому чтоmainможет содержать недоделанную работу. - Ад слияний. Длинные ветки, живущие неделями, расходятся так далеко, что реинтеграция превращается в многочасовую сессию разрешения конфликтов.
- Сломанная общая ветка. Когда ничего не защищено, один плохой пуш ломает сборку всей команде.
- Хотфиксы, спутанные с фичами. Когда нет отдельного пути для срочных правок, однострочный патч безопасности уезжает только вместе с недоделанной работой.
Workflow существует именно для того, чтобы сделать каждый из этих случаев невозможным по структуре, а не за счёт того, что все помнят про осторожность.
Четыре оси различают любой workflow, который тебе встретится. Когда ты сравниваешь git-flow, GitHub flow и trunk-based development, ты на самом деле сравниваешь четыре регулятора:
- Число долгоживущих веток. Долгоживущая ветка — это та, что никогда не удаляется и копит историю вечно (
main, иногдаdevelop). Одна? Две? Это число — самое крупное структурное различие. - Время жизни рабочих веток. Фичеветки живут часы, дни или недели до слияния?
- Частота релизов. Ты деплоишь непрерывно на каждом слиянии или нарезаешь версионные релизы (1.4.0, 1.5.0) по расписанию?
- Момент интеграции. Ты вливаешь работу в общую линию непрерывно (много раз в день) или большими партиями в конце?
Каждый workflow в этом юните — это просто конкретная настройка этих четырёх регуляторов, выбранная под конкретный тип команды и модель релизов.
▸Почему это работает
Почему доминирует именно число долгоживущих веток? Потому что долгоживущие ветки — это место, где копится расхождение. Каждая из них — отдельная временна́я линия, которую рано или поздно нужно согласовать с остальными, а цена согласования растёт с тем, как долго и как далеко они разошлись. Workflow с одной долгоживущей веткой (GitHub flow, trunk-based) структурно минимизирует расхождение; workflow с несколькими (git-flow: main плюс develop плюс релизные ветки) покупает гибкость для версионных релизов ценой постоянного межветочного слияния. Почти любой компромисс в этом юните восходит к этому единственному регулятору.
Защищённая ветка — это то, как контракт принуждается, а не просто документируется. Защищённая ветка — это ветка, в которую платформа (GitHub, GitLab) отказывается пускать прямой пуш: изменения должны приходить через pull/merge request, прошедший обязательные CI-проверки и ревью. Именно это превращает workflow из вики-страницы, которую никто не читает, в правило, принуждаемое инструментом. Защита main — единственный элемент каждого workflow в этом юните, который не обсуждается: именно он гарантирует, что ветка — источник истины всегда отревьюена и всегда зелёная.
Диагностика команды в беде.
Команда из шести человек жалуется, что «git — это бардак». Ты задаёшь четыре вопроса — четыре оси. Их ответы: долгоживущие ветки? Только main, но она не защищена, так что любой пушит что угодно. Время жизни ветки? У одного инженера фичеветка открыта 19 дней. Частота релизов? Они деплоят main, когда кому-то захочется. Момент интеграции? Большим взрывом — 19-дневная ветка приедет целиком на следующей неделе.
В git ничего не сломано. Диагноз выпадает прямо из осей: незащищённый main (риск сломанной сборки), одна сбежавшая долгоживущая ветка (риск ада слияний) и нет определённой точки релиза (никто не знает, что живое). Лечение — не git-команда, а принятие workflow: защитить main, ограничить время жизни ветки днём-двумя и определить «слияние в main = деплой». Это по сути GitHub flow, к которому подводят следующие уроки.
▸Частая ошибка
Частая ошибка — считать «мы используем git» за workflow. Git — это инструмент; workflow — это договорённость о том, как им пользоваться. Две команды могут обе «использовать git» и иметь совершенно несовместимые правила: одна нарезает версионные релизные ветки, другая деплоит каждое слияние. При онбординге важен вопрос не «используете ли вы git», а «какие ветки долгоживущие, что защищено и что запускает слияние в главную линию». Если команда не может ответить на это — у неё есть инструмент, но нет workflow.
Какая из этих осей сильнее всего структурно разделяет три workflow этого юнита?
Workflow ветвления — это согласованный командой контракт о том, как код движется от идеи к ревью и в продакшен: какие ветки существуют, что защищено, как нарезаются релизы и как делаются хотфиксы. Без него ты ловишь четыре предсказуемых отказа: нет точки релиза, ад слияний, сломанная общая ветка и хотфиксы, спутанные с фичами. Каждый workflow — это настройка четырёх регуляторов: число долгоживущих веток, время жизни ветки, частота релизов и момент интеграции, и число долгоживущих веток доминирует над остальными. Дальше ты встретишь самую тяжёлую из трёх моделей — git-flow — и увидишь, почему все эти долгоживущие ветки одновременно помогают и вредят.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.