Гитсинк и гитконвертер умеют определять, доступна ли инкрементальная выгрузка, и дропают каталог выгрузки целиком, если недоступна

Эта модель родилась в 2010 году — более 10 лет назад — практически сразу после того, как появился Git. Приобрела настолько высокую популярность у разработчиков, что ее начали рассматривать как своего рода стандарт — но, к сожалению, и как некую догму или панацею.
Сегодня, приложения разрабатываются в рамках подхода CD, не откатываются и не требуют поддержки нескольких одновременно запущенных версий ПО.
Это вовсе не тот класс ПО, который я имел в виду, когда писал свою статью десять лет назад. Командам, занимающимся непрерывной доставкой ПО, я бы рекомендовал использовать гораздо более простой рабочий процесс (вроде GitHub flow) вместо того, чтобы пытаться интегрировать Git-flow в свою работу.
В свою очередь, Git-flow может подойти командам, которые разрабатывают ПО с жестким версионированием или занимаются поддержкой нескольких версий приложения параллельно.
Учитывайте свои условия, контекст и думайте своей головой!
5 марта 2020
Vincent Driessen - автор концепции.

Сабтаски нельзя привязывать к релизам, что прилично обламывает(

в 2020 году на реддите (Please stop recommending Git Flow!) это все активно обсуждалось по итогу остановились на том, что git-flow применим только в двух случаях 1) Если ваша компания придерживается месячного или квартального цикла выпуска ПО или реже выпускает релизы. 2) Если команда насчитывает 20+ человек, работающих над параллельными релизами. Если вы не подходите под  условия (1, 2) то git-flow подарит вам лишние накладные расходы. Такой мировой опыт сейча (2020 год), с 1,2 согласен и сам автор концепции - он создавал ее для разработки ОС и прочих крупных блоков, в не для мелочевки скриптов  1С, Web и прочего.

Я читал что-то с похожим названием, но мне нравится организованность git flow и пока дополнительные расходы невелики, а проблемы в основном связаны с тем, что мы находимся на промежуточном этапе от конфигуратора с хранилищем к гиту с EDT. По крайней мере план такой. И возможно она нам сейчас подходит поскольку релизы у нас достаточно редки по современным меркам - порядка 1 в 2 недели. Возможно когда мы перейдем на более частую и регулярную поставку от гит флоу придется отказаться.

Зелёный девелопер... Как звучит!
Потребляет углекислого "кода" больше, чем вырабатывает?

Бегает с единомышленниками взад-назад и ломает работу нефтедобытчикам😂

нужно понимать, что в модели Github flow есть явные предпочтения быстрому\частою деплою основной ветки мастер в продуктив
т.е. мастер - это оттестированный стабильный вариант, фактически развернутый в проде

Но чтобы попасть в мастер вам нужно пройти минимум "два круга ада" фиче ветки и девелоп ветку. При этом под фичей понимают все что угодно кроме того что имел в виду автор концепции. В контексте 1с фичей является подсистема целиком/технический проект но никак не задача на разработку прав доступа к документу. Поэтому и возникает проблема траты кучи времени на создание, слияние веток ради задачи длительностью 2 часа. Ветка должна жить долго минимум месяц разработки

Эм, а почему "в контексте 1С фичей является подсистема" ?

Ну вообще не 2, а три, если прям классичейский git-flow.
1. Сначала feature для разработки
2. Потом develop для накопления грязных изменений
3. Потом release для стабилизации передвмерджевыванием в master

В гитхаб флоу нет девелопа

Я удивлён тезисом про минимум месяц. Весь гит-флоу построен вокруг быстрого развития и частотного мержа в девелоп. Долгие фича-бранчи - это скорее проблема, чем "надо делать только так"

в github flow нет dev и release потому там все проще, но без хорошего покрытия на CI есть риск что ты будешь жить с master веткой как с dev веткой и периодиески придется вводитьмараторий на мерджи пока не стабилизируешь код прям в master

А мы про  git flow, поэтому и появились другие варианты т.к именно git flow  он с когкретными наклабными расходами, нормальными для крупных проектов и ненужными для веб и 1с скриптов

+ в чем смысл тогда вообще в использовании гита, если в итоге один коммит будет равен внесению подсистемы по итогам месяца разработки? В рамку повесить?

Вы ответили на сообщение в котором писалось про гитхаб флоу

Если не сквошить, то будет полная история

Щас бы 20 коммитов устранения замечаний сонара в мастер лить

выше была прямая речь автора git flow для чего он его создавал. Если вы используете для другого то это уже методика вашего имени.