Git и хранилище 1С: как жить двум мирам

В 1С «система контроля версий» для многих до сих пор = хранилище конфигурации. Параллельно команда тянет Git (часто через EDT или выгрузку XML) — и получается два источника правды, конфликты «кто последний захватил» и страх обновляться. Публичные практики Infostart/EDT сходятся: хранилище — про захват объектов в конфигураторе; Git — про ветки, ревью и историю диффов. Жить можно обоим, если роли разделены.

Я выстраиваю процесс под размер команды, не под моду. Настройка контура и обучение — от 2 999 ₽/час; сопровождение разработки — в абонементе от 49 999 ₽/мес: услуги.

Зачем хранилище до сих пор нужно

• захват/освобождение объектов в классическом конфигураторе;
• привычный поток для «один основной разработчик + иногда второй»;
• меньше сюрпризов, если команда не на EDT.

Слабые места: слабая история «почему так», плохое ревью, соблазн править мимо хранилища «на пять минут».

Зачем Git

• ветки под задачу, merge request, понятный diff;
• связь с тикетом и CI (синтаксис, дымовые тесты — по зрелости);
• онбординг нового разработчика без археологии чатов;
• EDT-центричный процесс, где хранилище — опциональный мост.

Слабые места на старте: кривая обучения, соблазн «выгрузил XML руками и забыл», рассинхрон с продовым хранилищем.

Рабочая схема для малого контура

1. Прод не место для экспериментов — только через копию и релиз.
2. Один «канареечный» контур разработки (или EDT + Git).
3. Хранилище — если конфигуратор остаётся основным инструментом захвата.
4. Git — обязателен, если больше одного активного разработчика или нужны ревью.
5. Список расширений и внешних отчётов — отдельно от «магии в чате».

Не нужно внедрять Git «потому что модно», если один человек правит раз в квартал. Нужно — когда уже теряете, кто и когда сломал проведение.

Самопроверка

1. Есть ли список доработок и расширений с владельцем?
2. Правите ли прод напрямую мимо хранилища/ветки?
3. Есть ли тестовая база, обновляемая не реже релиза?
4. Понятно ли, как откатиться на вчерашний cf/cfe?
5. Согласованы ли правила: кто мержит в main / кто кладёт в хранилище?

Типичные ошибки

• Два Git-репозитория «на всякий случай» без owner.
• Правка на проде + потом «как-нибудь выгрузим».
• Хранилище без дисциплины захвата (всё захвачено одним человеком на месяц).
• Git без соглашения об имени веток и размере коммита.

Как я обычно внедряю

1. Аудит текущего потока (кто, чем, куда кладёт).
2. Минимальный регламент на одну страницу.
3. Пилот на одной задаче end-to-end.
4. Чеклист релиза: копия → сравнение → смок → прод.
5. Ретро через 2 недели — убрать лишнее.

15+ лет в enterprise-контурах: видел и «только хранилище», и «Git ради Git». Напишите размер команды и EDT/конфигуратор — предложу схему без бюрократии на 40 страниц.