Давайте продолжим. Какие могут быть недостатки у подхода gitflow? 1. Множество долгоживущих веток. Две очевидные "вечные" ветки - master и develop 🟡. При этом фича-ветки в классическом gitflow тоже не ограничены по времени жизни. Разрабатывайте свою фичу хоть три года, куда спешить. Если релизные ветки создаются под каждый релиз и потом закрываются, это еще полбеды. Совсем плохо, когда команда проекта использует отдельную долгоживущую ветку releases 🟢 просто потому, что они так поняли картинку, но текстовое описание флоу не прочитали 🤦‍♀️ Это могло бы показаться шуткой, если бы не повторялось десятки раз 2. Неоднозначность разрешения конфликтов. Конфликты при объединении веток неизбежны и рано или поздно случаются. При этом то, как такой конфликт разрешается - на совести разработчика, решающего конфликты вручную. Тот, кто хоть раз сталкивался с подобной задачей на большом объеме кода, знает, насколько хрупко равновесие проекта в этот момент 🤞 На картинке, если коммит из hotfix 🔴 попадает в develop 🟡 с конфликтом из-за того, что там уже произошли какие-то изменения после релиза, то это неизбежно приведет к расхождению master 🔵 и develop 🟡 с непредсказуемым результатом в будущем. При использовании gitflow обычно к каждой ветке привязано свое окружение и этим объясняется необходимость долгоживущих веток. Например, весь код из develop 🟡 собирается и попадает на стенд разработки, из releases 🟢 - на stage для тестирования, из master 🔵 - на продакшн. Вроде бы логично, понятно и удобно, если вас не смущает то, что на стейдже вы тестируете один код, а на продакшн выкладываете другой 🤷