Что такое git flow

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

Работали ли вы в команде с договорённостями о ветках и понимаете ли, под какой процесс поставки подходит эта модель. Следом почти всегда спрашивают, чем git flow отличается от GitHub flow и trunk-based development и что использовали вы.

Как отвечать

Git flow это модель ветвления, которую Винсент Дриссен описал в 2010 году. Ветки делятся по назначению:

• main (master): только выпущенные версии, каждый релиз помечен тегом вроде v1.4.0;
• develop: интеграционная ветка, куда вливаются готовые фичи;
• feature: ветки feature/* ответвляются от develop и возвращаются в неё;
• release: ветки release/* отрезаются от develop для стабилизации. В них поднимают версию и правят баги, затем вливают в main и обратно в develop;
• hotfix: срочные исправления от main, вливаются и в main, и в develop.

Слияния делают с --no-ff, чтобы история фичи оставалась видна. Есть расширение git-flow с командами git flow feature start и git flow release finish, но это лишь автоматизация тех же merge и тегов.

В Python-мире модель хорошо ложится на библиотеку, у которой параллельно поддерживается несколько версий: в релизной ветке меняют версию в pyproject.toml или берут её из тега через setuptools-scm, а публикацию в PyPI запускает CI по тегу. Для сервиса на Django или FastAPI, который деплоится несколько раз в день, git flow тяжеловат. Сам автор в 2020 году дописал к статье, что для непрерывной поставки лучше подходит модель попроще вроде GitHub flow.

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

Путают git flow с GitHub flow. Во втором есть только main и короткие ветки под пулреквест, без develop и релизных веток.

Забывают влить hotfix в develop. Исправление уходит в прод, а в следующем релизе баг возвращается.

Держат фичевые ветки неделями. В Python-проекте это особенно больно на миграциях: две ветки создают миграции Alembic от одной ревизии, и после слияния alembic upgrade head падает из-за нескольких heads, а Django требует makemigrations --merge.