https://bool.dev/blog/detail/git-branching-strategies
Модель Git-flow сложна даже в том случае, если на минуту забыть о микросервисах и непрерывной доставке (continuous delivery, CD). Посмотрите-ка на эту схему и рискните сказать, что она интуитивно понятна:
В git'е число merge-конфликтов в ветке растет пропорционально числу людей, делающих коммиты в эту ветку. В случае Git-flow это число растет еще быстрее, потому что есть три других ветки (с разной продолжительностью жизни), которые сливаются в develop: ветви функциональностей, релизов и исправлений. Таким образом, потенциальное количество merge-конфликтов теперь минимум в три раза выше.
Потенциальную сложность, связанную с появлением всех этих ветвей, невозможно игнорировать. Такой подход подошел бы для организации с низкой частотой коммитов, но для любой динамично развивающейся компании или стартапа он не пригоден.
Перебазирование — это многогранный вопрос. Сторонникам Git-flow придется отказаться от перебазирования: ведь оно происходит вместе со слиянием, в результате которого две ветви объединяются. А учитывая проблемы Git-flow с наглядностью, вам будет необходим способ визуально отслеживать ветви. Чтобы этим не заниматься, придется навсегда забыть о rebase.
Continuous delivery — это практика, при которой разработчики выпускают обновления непосредственно в production (на самом деле, путем слияний с мастером) в автоматическом режиме. А теперь посмотрите на бардак, который творится в Git-flow, и объясните мне, как вы собираетесь проводить непрерывную доставку всего этого?
Вся модель ветвления основана на предсказуемом, долгосрочном цикле релиза новых версий, а не на выпуске нового кода каждые несколько минут или часов. Реализовать это слишком сложно, не говоря уже о принятой в CD практике накатывать исправления «на месте», в то время как Git-flow рассматривает исправления как отдельную сущность, которую необходимо бережно хранить, контролировать ее, держа отдельно от остальной работы.
Если ваша компания придерживается месячного или квартального цикла выпуска ПО, а команда параллельно работает над несколькими релизами, то Git-flow может стать неплохим выбором.
Для стартапа, сайта или веб-приложения со множеством релизов каждый день Git-flow не подходит. Если команда разработчиков невелика (менее 10 человек), то Git-flow вносит в ее работу слишком много церемоний и лишних движений.