Как я перестал беспокоиться и стал коммитить в GIT на большом 1С-Битрикс проекте

Тогда вообще непонятна причина отсутствия готовых скриптов, принимающих параметры, на выполнение одних и тех же операций.

Ну у нас ситуация попроще была. Хоть как-то процесс был выстроен, SVN использовался (пускай без веток и хотя по результатам ревизии на боевом сервере нашлось не менее сотни незначительных отклонений от репозитория). После вливания всех изменений в свн репозиторий и импорта его в git, было объявлено, что с этих пор никаких ручных правок или деплоя с дев-машин путем копирования изменений, лишь потому что деплой будет осуществляться через rsync без подтверждений перезаписи и с удалением файлов в десте, которых нет в сорсе и игнорлисте. Потом написаны скрипты для деплоя на тестовый сервер (использовался и как приемочный, и как обучающий для новых сотрудников или при введении глобальных фич) произвольной ветки любым разработчиком, а на боевой только главной, с правом мержить в главную и деплоить на боевой строго ограниченным кругом лиц (де-факто мною, плюс в теории могут главный админ и директор ИТ-департамента). Чуть позже разделили функции обучающего и приемочного серверов, обучающий теперь деплоится время от времени с главной ветки (по сути синхронится с боевым), а приемочный (у нас препрод называется, аналог вашего прелайва), а приемочный с любой. В ближайших планах то ли создать каждому разработчику отдельный виртуальный хост на препроде, то ли использовать что-то типа докера для поднятия виртуальных хостов под каждую фичу/баг/ветку, чтобы мог «полуофициально» давать заказчику конкретной фичи возможность предварительного тестирования, чтобы в идеале было минимум замечаний с препрода, чтобы он отличался от боевого лишь на один коммит и деплоился со специально отведенной ветки, в которую разработчики будут мержить изменения с тикет-веток и откатывать свой мерж, если возвращено на доработку.

Из технических проблем, общего решения которых не найдено пока, сейчас по сути только необходимость ручного управления миграциями при переключении препрода с одной ветки на другую, если в них есть изменения схемы и(или) справочников БД. Используемый инструментарий миграций совсем к работе с ветками не приспособлен, учитывает их, грубо говоря, по номерам, присваиваемым каждый раз заново на момент на момент запуска миграции по, грубо говоря, дате создания. То есть, если в одной ветке сейчас создать миграцию, во второй через 5 минут, запустить вторую миграцию, потом переключиться на первую ветку, то система будет уверена, что все миграции применены, потому что у первой тот же номер, что у второй, пока они не слиты вместе, а когда сольются, то система будет уверена, что применена первая, а вторую только нужно применить, хотя дело обстоит ровно наоборот. И такая дребедень даже если миграции никак не пересекаются.

Из организационных проблем — заставить разработчиков (себя в том числе) следить за миграциями (особенно за добавлением записей в справочники) и делать атомарные коммиты, а не аккумулирующие несколько этапов типа начали писать новую фичу, написав с треть предполагаемого кода узнали про готовое решение второй трети, заинтегрировали его, дописали последнюю треть и закоммитили одним коммитом и интеграцию, и готовое решение, вместо того, чтобы или коммитить сначала интеграцию (можно стэшем воспользоваться например), потом полное решение, или наоборот, или хотя бы три коммита сделать.

Ладно вам набрасывать Битрикс на вентилятор. руки, мозги, Битрикс, PHP и 1С никак не связаны и одно другому не мешает/не помогает.