Git сам по себе не навязывает никакого порядка. Он умеет коммитить, ветвить и сливать - и ему все равно, как ты этим пользуешься. Можно держать сто веток и сливать их раз в полгода, можно работать прямо в одной ветке вдвадцатером. Технически и то и другое валидно. Боль начинается, когда вас больше одного.
Представь: пятеро программистов, у каждого своя ветка, каждая живет три недели. В пятницу все одновременно решают влиться. Один трогал тот же файл, что и другой; третий за это время отрефакторил половину модуля. Получаешь день мучительных конфликтов, ночной хотфикс на проде и вопрос "а что вообще сейчас в релизе". Это не проблема Git - это отсутствие договоренности. Рабочий процесс git (он же git workflow) - это и есть писаное правило: где живет стабильный код, как заводят ветку под задачу, когда и куда вливают, как выкатывают релиз и как тушат пожар на проде.
Хорошая модель ветвления отвечает на четыре вопроса. Откуда я ответвляюсь? Куда вливаюсь обратно? Сколько живет моя ветка? Что считается "готовым к релизу"? Дальше разберем главные ответы индустрии - от самого тяжелого к самому легкому - и честно скажем, что брать в 2026, а что уже музейный экспонат.
Централизованный поток и Feature Branch Workflow
Самый примитивный вариант - централизованный поток, наследие SVN. Все коммитят в одну ветку (main), как будто это общий сервер. Перед push делаешь pull/rebase, разруливаешь конфликты, отправляешь. Работает только для двух-трех человек, которые редко пересекаются. Ревью нет, история линейная, любая полусырая правка сразу в общей ветке. Для учебного пет-проекта - сойдет, для команды - нет.
Следующая ступень - Feature Branch Workflow. Идея простая: main всегда зеленый и деплоится, а любая работа идет в отдельной ветке-фиче (feature branch). Закончил - открываешь pull request, проходишь ревью, вливаешь.
Код: Выделить всё
git switch main
git pull
git switch -c feature/export-csv
# ... коммиты ...
git push -u origin feature/export-csv
# открываешь PR, проходишь ревью, мержишь
Feature Branch - это фундамент. Все три "взрослые" модели ниже - это по сути разные политики поверх него: чем отличаются ветки, как долго живут и куда вливаются.
GitFlow - тяжелая модель и честный взгляд из 2026
GitFlow придумал Винсент Дриссен в 2010 году, и на десятилетие он стал почти синонимом слова "правильно". Схема жесткая и многоэтажная. Две вечные ветки: main (только релизы, каждый коммит - версия) и develop (интеграционная, сюда стекаются фичи). Плюс три типа временных:
- feature/* - ответвляется от develop, вливается обратно в develop;
- release/* - ответвляется от develop при подготовке релиза; тут только стабилизация и багфиксы; по готовности вливается в main И обратно в develop, на main вешается тег версии;
- hotfix/* - ответвляется от main для срочной правки прода, вливается и в main, и в develop.
Код: Выделить всё
# старт фичи
git switch develop && git pull
git switch -c feature/payments
# подготовка релиза
git switch -c release/1.4.0 develop
# багфиксы, бамп версии...
git switch main && git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop && git merge --no-ff release/1.4.0
# пожар на проде
git switch -c hotfix/1.4.1 main
# правка...
git switch main && git merge --no-ff hotfix/1.4.1 && git tag -a v1.4.1 -m "Hotfix"
git switch develop && git merge --no-ff hotfix/1.4.1
Зачем такая сложность? GitFlow заточен под версионный софт с явными релизами: десктопные приложения, мобильные с долгим ревью в сторах, прошивки, библиотеки, поддержка нескольких версий параллельно. Там реально нужна отдельная ветка стабилизации и аккуратные хотфиксы по старым версиям.
Теперь честно про 2026. Для веба и SaaS, где деплоят по десять раз в день, GitFlow - это лишний жир. Сам Дриссен еще в 2020-м добавил к статье примечание: если у вас continuous delivery, не тащите эту модель, она не для вас. Главные претензии: длинные feature-ветки копят дельту и взрываются конфликтами при вливании; ветка develop почти всегда расходится с main и порождает вопрос "что же реально в проде"; пять типов веток - это пять способов ошибиться джуну. В 2026 GitFlow жив в нишах с настоящими версиями и редкими релизами. Если ты не уверен, нужен ли он тебе, - значит, не нужен.
GitHub Flow - дефолт, с которого начинают
GitHub Flow - радикальное упрощение. Никакого develop, никаких release-веток. Одна вечная ветка - main, которая всегда деплоится. Все остальное - короткие ветки от main и обратно в main через pull request.
Полный цикл:
- ответвись от main осмысленным именем (fix/login-timeout);
- коммить, пушь, открывай PR рано - PR это место для обсуждения, а не финальный отчет;
- прогоняется CI, идет ревью;
- зеленый и одобренный PR вливается в main;
- деплой - сразу или почти сразу после мержа.
Код: Выделить всё
git switch main && git pull
git switch -c fix/login-timeout
# правка + коммит
git push -u origin fix/login-timeout
gh pr create --fill # если стоит GitHub CLI
Код: Выделить всё
git config --global push.autoSetupRemote true
Слабое место GitHub Flow одно: он подразумевает, что слитое в main можно быстро выкатить. Если у тебя долгий ручной релиз раз в квартал, "main всегда деплоится" превращается в фикцию. Тогда либо налаживай CD, либо смотри в сторону trunk-based с релизными ветками-срезами.
Trunk-Based Development - куда идет индустрия
Trunk based development (TBD, разработка в стволе) - это GitHub Flow, доведенный до предела. Ствол (trunk - тот же main) - единственный источник правды, и ветки живут не дни, а часы. Правило простое и жесткое: ветка короткоживущая, меньше суток, вливаешься в trunk минимум раз в день, а лучше чаще. Разработчики постарше иногда коммитят прямо в trunk маленькими порциями (с обязательным ревью), но мейнстрим-вариант - крошечные PR с быстрым мержем.
Почему именно сюда идет индустрия в 2026. Чем дольше ветка живет в стороне, тем сильнее она расходится со стволом - дельта растет нелинейно, и стоимость вливания тоже. Короткие ветки держат расхождение около нуля: конфликты мелкие и частые, а мелкий частый конфликт несравнимо дешевле большого редкого. Это прямая интеграция в чистом виде - то самое CI, ради которого все затевалось.
Но тут же возникает противоречие, которое надо честно проговорить. "Сливай недописанную фичу в trunk каждый день" звучит как рецепт катастрофы. Спасают два обязательных компонента - без них TBD не работает.
Первое - feature flags (фичефлаги). Код фичи вливается в trunk выключенным под флагом. Он есть в кодовой базе, ездит в проде, но для пользователей погашен, пока ты не дописал и не проверил. Так "слить недоделку" и "показать недоделку юзеру" - это два разных события, разнесенных во времени.
Код: Выделить всё
if (features.isEnabled("export-csv", user)) {
return renderExportButton();
}
Второе - merge queue (очередь слияния), при частых вливаниях не опция, а обязательный компонент. Проблема такая: десять PR по отдельности зеленые на CI, но каждый тестировался против старого main. Влил все десять - и main красный, потому что вместе они не дружат. Это классика: "PR прошел, а main все равно сломался". Очередь слияния решает это так: она ставит готовые PR в линию, берет следующий, временно прицепляет его поверх АКТУАЛЬНОГО состояния всех предыдущих в очереди, гоняет CI именно на этой комбинации - и вливает, только если зелено. Main гарантированно остается рабочим.
На GitHub в 2026 merge queue в общем доступе и включается через repository rulesets - новую систему правил, на которую GitHub переводит команды со старой classic branch protection (rulesets как раз вышли в GA). Критичная деталь: чтобы CI отрабатывал внутри очереди, твой workflow должен слушать событие merge_group, а не только pull_request. Забыл - и проверки в очереди просто не запустятся, а ты будешь думать, почему PR висит. У GitLab аналог - Merge Trains.
Код: Выделить всё
on:
pull_request:
merge_group: # без этой строки очередь не запустит проверки
Код: Выделить всё
git rebase --update-refs main
Forking Workflow для open-source
Отдельная модель для ситуации, когда у контрибьютора нет и не должно быть прав на push в основной репозиторий, - Forking Workflow. Ты не ветвишься внутри чужого репо, а делаешь форк (личную копию на сервере), работаешь у себя и присылаешь pull request из своего форка в апстрим.
Код: Выделить всё
# origin - твой форк, upstream - оригинал
git remote add upstream https://github.com/orig/project.git
git fetch upstream
git switch -c fix/typo upstream/main
# правка, push в origin (свой форк), затем PR в upstream
git fetch upstream && git rebase upstream/main # подтянуть свежий апстрим
Как выбрать под свою команду
Не существует "лучшей" модели - есть подходящая под твой релиз-цикл и зрелость. Конкретные критерии:
- Релизишь по нескольку раз в день, есть CD - GitHub Flow или trunk-based.
- Релиз раз в квартал, поддержка нескольких версий, прошивки/десктоп/мобайл со стором - тут GitFlow оправдан, ветки release/hotfix реально нужны.
- Команда из 1-5, джуны, нет выделенного devops - GitHub Flow, не усложняй.
- Большая команда, быстрый CI, культура мелких изменений - trunk-based с фичефлагами и merge queue.
- Внешние контрибьюторы без прав на запись - Forking Workflow.
Мини-лаба: прожить три модели руками
Сделай локальную песочницу и пощупай разницу.
Код: Выделить всё
mkdir flow-lab && cd flow-lab && git init -b main
git commit --allow-empty -m "init"
# --- GitHub Flow ---
git switch -c feature/hello main
git commit --allow-empty -m "feature work"
git switch main && git merge --no-ff feature/hello -m "merge feature/hello"
# --- кусочек GitFlow ---
git switch -c develop main
git switch -c feature/login develop
git commit --allow-empty -m "login"
git switch develop && git merge --no-ff feature/login -m "merge login"
git switch -c release/1.0 develop
git switch main && git merge --no-ff release/1.0 -m "release 1.0"
git tag -a v1.0 -m "v1.0"
# посмотри обе истории
git log --oneline --graph --all
Контрольные вопросы
- Почему в trunk-based короткие ветки дешевле длинных - что именно растет со временем жизни ветки и почему нелинейно?
- Зачем feature flags именно в trunk-based, и какие два разных события они разносят во времени?
- Какую конкретную проблему решает merge queue, чего не ловит обычный зеленый CI на отдельном PR?
- По каким критериям ты выберешь GitFlow вместо GitHub Flow, и почему обратный выбор для джуна обычно ошибка?
Модель ветвления - это договор команды, а не свойство Git. Централизованный поток годится двум людям, Feature Branch - фундамент для всех. GitFlow тяжелый и в 2026 оправдан только при настоящих версиях и редких релизах. GitHub Flow - дефолт для джуна и небольшой команды, бери его и не усложняй. Trunk-based - туда идет индустрия, но он требует фичефлагов и merge queue. Forking - для open-source без прав на запись. Выбирай по релиз-циклу и зрелости, начинай с простого и усложняй только под реальную боль.
