Есть мастер, есть релизы бранчи. Все остальное short-lived branches, включая feature, hotfix, bugfix etc. Создаются и уничтожаются по факту мержа либо в мастер либо в релиз. hotfix/bugfix могут мержится в несколько мест (см. черрипикинг), если проблема в релиз бранче — но самое простое и чистое решение мержить фиксы в релиз и перед отдачей релиза/по мере необходимости мержить весь релиз в мастер (естественно, для этого есть какое то opportunity window, которое со временем закрывается).
Чем больше бранчей, тем больше проблем, количество параллельно поддерживаемых бранчей — главный источник сложности, зачем их плодить? За 10 лет я не видел нужды в develop бранче/где бы это использовалось.
по поводу политик — мне нравится как сделано в GitLab — protected branches, защищенные бранчи — в них нельзя мержить напрямую (или можно, но не всем), обычно это мастер, иногда релизы. Соответственно, для изменения кода необходимо создавать бранч и проходить через процедуру ревью и проверок перед мержем (например запуск тестов и код кавераджа). На практике этого хватает, усложнить, конечно, можно, но зачем?
релиз бранчи формируются и поддерживаются релиз инженером или равноправным лицом, это немного другая работа, нежели непосредственно разработка, но все решается в рамках скрума или для частных случаев митингами.
