Как организовать ветвление и деплой с использованием Git

Что проверяют

Есть ли у вас осознанный процесс от ветки до прода, а не набор команд git. Интервьюера интересует, как код попадает на сервер, что происходит с миграциями и как откатиться. Следом часто спрашивают, почему выбрана именно эта модель ветвления.

Как отвечать

Назовите модель и условие, при котором она работает:

• GitHub Flow или trunk-based: одна main, короткие ветки на задачу, живут день или два. Незаконченное прячется за фича-флагами. Подходит веб-сервисам с частыми релизами;
• Git Flow: ветки develop, release/*, hotfix/*. Оправдан, когда параллельно поддерживаются несколько версий, например у библиотеки или коробочного продукта. Для сервиса с одной версией в проде это лишняя бюрократия.

Затем конвейер:

• pull request и CI: в ветке прогоняются pytest, ruff, mypy, ветка main защищена, слияние только с зелёными проверками и после ревью;
• артефакт собирается один раз: из коммита в main получается Docker-образ с тегом по SHA, и этот же образ едет на стейджинг и в прод. Сервер не делает git pull и ничего не собирает сам;
• релизы: теги вида v1.4.0 или автоматический деплой каждого коммита в main, ручное подтверждение через environments в CI;
• миграции: Alembic или Django migrations пишутся обратно совместимыми по схеме expand и contract, потому что во время раскатки старая и новая версия кода работают с одной базой;
• откат: повторный деплой предыдущего образа, а не git revert в спешке на сервере.

Где спотыкаются

Держат feature-ветки неделями. Слияние превращается в разбор конфликтов, а интеграционные баги всплывают в последний день.

Деплоят через ssh и git pull на сервере. Сборку нельзя повторить, зависимости ставятся на живой машине, откат требует ручных действий.

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