IaC, отдельный branch под одно окружение или один branch под все окружения

Лучше разделять всё, что разделяется. Потому используют CMake, который убирает целый слой окружения.

Второе. Недостаток первого, например, в том, что когда у тебя огромная инфраструктура и 15-30 системных инженеров, все заколебутся разруливать конфликты в гите и будут мешаться друг у друга под ногами при попытке что-то помержить в мастер.

Первый - это для разработки (новой роли, например) и тестирования. Лепишь бранч с именем тикета и работаешь, как тебе угодно. А когда готово, тебе сделают ревью и помержат.

Если речь именно про инфру, то второй подход надёжнее. А если ты туда ещё свою приложеньку будешь деплоить, то тут есть несколько вариантов, и все правильные.

Подвожу выводы: Вариант все окружения в одном брэнче удобнее для поддержки чего-то уже готового с небольшими изменениями. Если идет речь о серьезной переработки существующей системы с отладкой, выгоднее вынести ее окружение в отдельный брэнч и там допиливать зная, что остальные не пострадают в процессе. С другой стороны, если хочешь перейти из первого пункта во второй, нужно сразу писть код с возможностью нескольких окружений в одном брэнче.

Вариант все окружения в одном брэнче удобнее для поддержки чего-то уже готового с небольшими изменениями

В обычных условиях инфра всегда развивается и меняется, не бывает такого, что запилил раз и навсегда. Появляются новые сервисы и роли, аппликухи переезжают в облако и обратно, обновляются операционные системы и т.д., всё это влечет постоянные изменения в коде инфры. Как я уже писал, правильно использовать оба подхода одновременно: бранчи для текущей разработки, а энв дефайнить переменными. Иначе, помимо лапши с гит-конфликтами, у тебя еще и энвы начнут сильно отличаться со временем и каждый перенос из одного энва в другой будет дикой жопоболью от количества переписывания.

С другой стороны, если хочешь перейти из первого пункта во второй, нужно сразу писть код с возможностью нескольких окружений в одном брэнче

Это довольно легко. Причем что на паппете, что на ансибле. Просто вытаскиваешь переменные, специфические для энва в отдельные места, и нигде в коде ничего не хардкодишь, а обращаешься к переменным. Сам энв проще всего дефайнить в хостнеймах 1-2 символами.

Я предпочитаю организовать дело так:

1. Есть модули. Это наши основные строительные кирпичи, из которых можно сделать что угодно. У модулей есть входные переменные, с помощью которых их можно уточнить и версии.
2. Есть окружения: это набор модулей определённых версий и параметров.
3. Prod и stage — должны состоять из тех же версий модулей, но stage может быть, например, чутка меньше по размерам, меньше узлов в группе или сами узлы поплоше да подешевле.
4. qa/dev — ссылаются на специальные ветви в модулях или же самоновейшие версии их.

Очевидно второй.

Первый сделан чтобы максимально запутать всех вокруг и стать кирпичиком в джоб секьюрити. Технически это просто N отдельных репозиториев засунутых благодаря гибкости гита в один.