Исходники в git, линт и quality gate как условие мерджа

Директивный

Правило

Конфигурация хранится в git как текстовые исходники (/DumpConfigToFiles в зафиксированном формате), а не только бинарный .cf — иначе нет диффов, ревью и линтера.
Изменение принимается только при зелёном линтере (BSL Language Server, профиль обязательных диагностик) и quality gate (SonarQube 1C, если развернут) для нового кода.
main защищён: прямые пуши запрещены, мердж — только через MR/PR с успешным CI и минимум одним ревью со стороны компании.
Ветки короткоживущие: feature/<задача>_<кратко>, срок жизни ~≤ 10 рабочих дней; размер MR ~≤ 500 строк диффа — большие изменения режутся на шаги.

Зачем

Без quality gate стандарт — это пожелание: подрядчик сдаёт как привык, замечания всплывают на приёмке и оплачиваются второй раз. Gate переводит правила из документа в механику: не проходит линтер — мердж закрыт, и спорить не о чем. Большие MR и долгоживущие ветки убивают ревью — проверяющий физически не может осмыслить 2000 строк, и дефекты проходят насквозь.

Подрядчик присылает .cf файлом в чате → загрузили в базу конфигуратором →
«ревью» = открыли пару модулей глазами → через месяц никто не помнит, что менялось.

Ветка feature/T-123_skidki → push → CI: BSL LS + тесты → quality gate PASS →
MR с описанием по шаблону → ревью → мердж в защищённый main → сборка поставки из CI.

Инструменты контура: BSL Language Server (.bsl-language-server.json в корне репозитория), SonarQube 1C (BSL) Community Plugin, OneScript + vanessa-runner для запуска конфигуратора из CI, precommit4onec для локальных хуков — ссылки в источниках. Готовые каркасы .gitlab-ci.yml / GitHub Actions / sonar-project.properties / .bsl-language-server.json и процедура отката — в шаблонах CI/CD.

Когда не применять

Для баз, где нет доработок (чистая типовая на поддержке), контур избыточен. Хотфикс «прод лежит» можно мерджить по упрощённой процедуре — но пост-фактум ревью и прогон CI обязательны в тот же день.