Что такое git flow и как он используется
Что проверяют
Знаете ли вы схему и понимаете ли, что сегодня она чаще избыточна. Хороший ответ включает альтернативы.
Как отвечать
Git Flow это модель ветвления с фиксированным набором ролей:
- main: только релизы, каждый коммит помечен тегом версии;
- develop: основная ветка разработки;
- feature/: ветки задач, ответвляются от develop и вливаются обратно;
- release/: подготовка релиза, только стабилизация и правки;
- hotfix/: срочные исправления от main, вливаются и в main, и в develop.
Где она уместна: продукт с явными версиями и долгой стабилизацией, несколько поддерживаемых версий одновременно, релизы раз в квартал. Например, коробочное или мобильное приложение с длинным ревью в магазине.
Где мешает: веб-продукт с выкладкой несколько раз в день. Тогда две долгоживущие ветки создают лишние слияния, ветки задач живут неделями и расходятся, а release-ветка становится ритуалом.
Альтернативы стоит назвать:
- trunk-based: одна основная ветка, короткие ветки задач на день-два, незаконченное прячется за флагами функциональности. Именно эту модель используют команды с непрерывной поставкой;
- GitHub Flow: main плюс ветки задач и пул-реквесты, деплой из main. Промежуточный вариант, самый распространённый.
Правильный вывод: модель выбирается под частоту релизов, а не наоборот.
Где спотыкаются
Называют Git Flow единственно правильным способом.
Держат ветки задач неделями и получают ад слияний.
Не могут объяснить, зачем нужна develop, если релиз идёт из main.
Не знают про флаги функциональности и потому считают trunk-based невозможным.