Регламент доступа к Git-репозиторию 1С: шаблон и ошибки

📅 Опубликовано 18 августа 2026 г.

Коротко: регламент доступа к Git-репозиторию 1С — это документ на 2–3 страницы, который фиксирует четыре вещи: матрицу ролей (Guest / Reporter / Developer / Maintainer / Owner), защиту веток master и release от прямого push, срок выдачи доступа (1 рабочий день) и срок отзыва при увольнении или окончании договора с подрядчиком (не более 2 часов). Без такого документа команда из 6 человек за год накапливает 10–20 «мёртвых» учётных записей, половина из которых имеет право писать в основную ветку.

• Минимум ролей — 4: читатель (аналитик, тестировщик), разработчик (feature-ветки), ревьюер/релиз-менеджер (merge в master), владелец (настройки проекта и токены). Пятая роль «все могут всё» — источник 90% инцидентов.
• Прямой push в master запрещён всем, включая владельца: изменения попадают в основную ветку только через merge request с минимум одним approve.
• Отзыв доступа быстрее выдачи: выдача — до 1 рабочего дня, блокировка при увольнении — до 2 часов, ревизия всех прав — раз в квартал.
• Персональные учётки, а не общая: одна учётная запись «podryadchik» на пятерых делает историю коммитов бесполезной для разбора инцидентов.
• Выгрузка конфигурации в файлы — часть регламента: правила именования веток, формат выгрузки (EDT или /DumpConfigToFiles) и запрет на коммит .cf, .dt и файлов с паролями фиксируются в том же документе.

Зачем нужен регламент доступа к Git-репозиторию 1С?

Пока разработка 1С жила только в хранилище конфигурации, вопрос доступа решался одной кнопкой: администратор хранилища добавлял пользователя и выдавал право захвата объектов. Переход на Git — через 1C:EDT, gitsync или собственные скрипты выгрузки — резко расширил периметр. В репозитории теперь лежит не просто конфигурация, а полная история изменений, скрипты сборки, файлы настроек подключения к базам, иногда — тестовые данные и фрагменты реальных выгрузок.

Практический риск выглядит так. Подрядчик закончил проект по доработке учёта, договор закрыт, акты подписаны. Через восемь месяцев выясняется, что его аккаунт в корпоративном GitLab жив, имеет роль Maintainer и по-прежнему видит весь код, включая доработки под новых клиентов компании. Формально нарушения нет — просто никто не описал процедуру отзыва. Второй сценарий: разработчик спешит перед релизом и делает push прямо в master, минуя ревью; ошибка в модуле проведения уезжает в продуктив, а откатить нельзя, потому что в ту же ветку успели влить ещё три коммита.

Регламент доступа закрывает оба сценария. Он не про бюрократию, а про три конкретных ответа: кто имеет право писать в репозиторий, куда именно он может писать и что происходит, когда человек уходит из проекта. Всё остальное — детали реализации в конкретном сервисе (GitLab, Gitea, Bitbucket, Azure DevOps).

Кто и какие права получает: матрица ролей

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

Роль в регламенте	Уровень в GitLab/Gitea	Кому выдаётся	Что может	Что запрещено
Наблюдатель	Reporter (20)	Аналитик, тестировщик, руководитель проекта	Читать код, смотреть историю, комментировать merge request, заводить issue	Создавать ветки, пушить, скачивать архив релизной ветки
Разработчик	Developer (30)	Штатный 1С-разработчик, внешний подрядчик на активном договоре	Создавать feature-ветки, пушить в них, открывать merge request, запускать пайплайн	Push в master/release, force-push, удаление веток, изменение защиты веток
Ревьюер / релиз-менеджер	Maintainer (40)	Тимлид, ведущий разработчик (1–2 человека на репозиторий)	Апрувить и вливать merge request, ставить теги релизов, управлять переменными CI	Апрувить собственные изменения, менять состав участников проекта
Владелец	Owner (50)	Руководитель ИТ или ответственный за инфраструктуру	Добавлять и удалять участников, настраивать защиту веток, выпускать deploy-токены	Разработка в этом же репозитории под ролью Owner (используется отдельная учётка)
Сервисная учётка CI	Deploy-token / Project access token	Сборочный сервер, робот выгрузки конфигурации	Клонировать репозиторий, пушить теги сборки	Интерактивный вход, доступ к другим проектам группы

Ключевой принцип — минимально достаточные права по умолчанию. Новый участник всегда получает Reporter, повышение до Developer оформляется отдельной заявкой с указанием проекта и срока. Для подрядчиков срок указывается обязательно и совпадает с датой окончания договора: это единственный надёжный способ не забыть про отзыв. Если вы работаете с внешней командой, условия доступа логично держать в одном пакете с соглашением об уровне сервиса с подрядчиком — тогда и сроки реакции, и правила работы с кодом описаны согласованно.

Шаблон регламента доступа к Git-репозиторию 1С

Ниже — рабочая структура документа. Формулировки можно копировать и адаптировать: они намеренно короткие, чтобы регламент читали, а не подшивали.

1. Область действия

Регламент распространяется на все репозитории группы 1c/ корпоративного Git-сервера, содержащие исходники конфигураций, расширений, обработок и скриптов сборки. Действие распространяется на штатных сотрудников, подрядчиков и сервисные учётные записи.

2. Термины

Репозиторий — Git-проект с исходниками конфигурации, выгруженными в формате EDT или конфигуратора. Основная ветка (master/main) — ветка, соответствующая коду в продуктивной базе. Релизная ветка (release/x.y) — ветка стабилизации. Feature-ветка — ветка задачи вида feature/ERP-1245-raschet-premii.

3. Роли и права

Приводится матрица из предыдущего раздела. Отдельным пунктом: «Совмещение ролей Ревьюер и Разработчик в рамках одной задачи не допускается — автор изменений не может самостоятельно влить свой merge request».

4. Порядок предоставления доступа

Основание — заявка в служебной системе (Jira, Service Desk) от руководителя подразделения или менеджера проекта. В заявке: ФИО, корпоративная почта, репозиторий, запрашиваемая роль, срок действия, номер договора для подрядчиков. Владелец репозитория предоставляет доступ в течение одного рабочего дня и фиксирует факт выдачи в реестре доступов.

5. Порядок отзыва доступа

Доступ отзывается: при увольнении — в течение 2 часов с момента получения уведомления от кадровой службы; при переводе в другой проект — в день перевода; при завершении договора подрядчика — в день подписания закрывающего акта; по истечении указанного в заявке срока — автоматически.

6. Правила работы с ветками

Прямая запись в master и release запрещена для всех ролей. Изменения попадают в защищённые ветки только через merge request с одним обязательным approve от Ревьюера и успешной сборкой. Force-push и удаление защищённых веток запрещены на уровне настроек сервиса.

7. Требования к содержимому репозитория

Запрещено коммитить: файлы *.cf, *.dt, *.epf в бинарном виде без согласования, файлы с паролями и строками подключения, персональные данные и выгрузки продуктивных баз. Секреты хранятся в переменных CI или в защищённом хранилище, а не в коде.

8. Ответственность и контроль

Ежеквартально владелец репозитория проводит ревизию списка участников и удаляет неактуальные доступы. Отчёт о ревизии направляется руководителю ИТ. Нарушение правил работы с защищёнными ветками фиксируется и разбирается на ретроспективе.

Регламент, который занимает больше трёх страниц, перестают открывать через месяц. Всё, что не влезло, выносите в отдельные инструкции: «Как настроить EDT», «Как выгрузить конфигурацию в файлы», «Как оформить merge request».

Как защитить ветки master и release от прямого push?

Регламент без технической реализации — это пожелание. Настройки, которые нужно включить в первый же день:

1. Protected branches для master и release/*: Allowed to push — No one, Allowed to merge — Maintainers.
2. Обязательный approve: минимум один, автор изменений не может апрувить себя.
3. Запрет force-push и удаления защищённых веток.
4. Обязательная успешная сборка перед merge: синтаксический контроль конфигурации, прогон дымовых тестов.
5. Подписанные или проверяемые коммиты: почта автора коммита должна совпадать с корпоративной, иначе конвейер падает.

Отдельно опишите, что именно проверяет ревьюер. Формальный approve «не глядя» обесценивает всю схему, поэтому чек-лист проверки лучше вынести в связанный документ — например, в регламент код-ревью доработок перед merge, где расписаны критерии приёмки кода и типовые замечания.

Выгрузка конфигурации в файлы для репозитория выполняется скриптом в пакетном режиме, а не руками. Это гарантирует единый формат и отсутствие «шумных» диффов:

REM Выгрузка конфигурации из хранилища в исходники для Git
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER ^
  /F "D:\bases\build_base" ^
  /N "BuildRobot" /P "%BUILD_PWD%" ^
  /ConfigurationRepositoryF "tcp://repo-server/erp" ^
  /ConfigurationRepositoryN "BuildRobot" ^
  /ConfigurationRepositoryP "%REPO_PWD%" ^
  /ConfigurationRepositoryUpdateCfg -v %1 -force ^
  /DumpConfigToFiles "D:\git\erp\src\cf" -Format Hierarchical ^
  /Out "D:\logs\dump.log" /DisableStartupMessages

Обратите внимание: пароли передаются переменными окружения сборочного агента, а не пишутся в скрипт. Это прямое требование пункта 7 регламента.

Как выдавать и отзывать доступ: процедура и сроки

Сроки — самая полезная часть документа: именно к ним апеллируют, когда что-то пошло не так. Практика показывает, что реалистичны такие значения.

Событие	Действие	Срок	Ответственный
Выход нового разработчика	Выдача роли Developer, добавление в проект	1 рабочий день с даты заявки	Владелец репозитория
Подключение подрядчика	Роль Developer с датой окончания = дата окончания договора	1 рабочий день	Владелец репозитория
Увольнение сотрудника	Блокировка учётной записи, отзыв personal access token	2 часа с уведомления HR	Администратор Git-сервера
Закрытие договора подряда	Удаление из проекта, ротация общих секретов	В день подписания акта	Менеджер проекта + владелец
Плановая ревизия прав	Сверка участников с реестром доступов	1 раз в квартал	Владелец репозитория
Компрометация токена	Отзыв токена, аудит push-операций за период	Немедленно, разбор — 1 рабочий день	Администратор Git-сервера

Для распределённых команд к этой таблице добавляют требования к рабочему месту: доступ только через VPN, запрет клонирования репозитория на личные устройства, обязательная двухфакторная аутентификация. Эти пункты обычно уже описаны в регламенте удалённой работы с 1С — в регламенте доступа достаточно дать ссылку, не дублируя текст.

Найдите специалиста для решения этой задачи на koderion.ru