Git для 1С вместо хранилища конфигурации: зачем переходить и как это сделать

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

Ниже — объяснение для руководителя и тимлида: в чём реальные ограничения хранилища, что меняет Git на конкретных рабочих ситуациях, какие подводные камни у 1С в Git и как провести переход без остановки разработки.

Ограничения хранилища конфигурации

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

• Захват объектов. Изменять объект может только тот, кто его захватил. Если два человека работают с одним документом или общим модулем, второй ждёт.
• Нет веток. Все изменения идут в одну линию. Срочное исправление и большая доработка живут в одной конфигурации, и выпустить одно без другого — ручная работа.
• Ограниченная история. Видно, какая версия изменила объект, но разбираться, кто и зачем поменял конкретную строку, долго.
• Сложный откат. Отменить одну задачу, когда после неё были другие, — ручное восстановление объектов.
• Слабая автоматизация. Сборка, проверки и тесты на каждое изменение в хранилище организовать трудно.

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

Что меняет Git: четыре рабочие ситуации

Получить актуальную версию

Хранилище: захватить объекты, обновить конфигурацию, разбираться с изменениями коллег, если они пересекаются с вашими.

Git: подтянуть изменения основной ветки в свою:

git fetch
git merge origin/develop

Никто никого не блокирует, своя работа не теряется. Команда работает параллельно, а не по очереди.

Отдать задачу на тестирование отдельно от остальных

Хранилище: выгружать объекты, переносить их в отдельную базу, следить, чтобы не утащить чужие незаконченные изменения.

Git: каждая задача — отдельная ветка. На тестовый стенд собирается именно она или нужный набор веток. Тестировщик проверяет точный набор изменений, а разработка продолжается.

Найти автора изменения

Хранилище: листать версии объекта и сравнивать.

Git: одна команда показывает автора, дату и комментарий для каждой строки модуля:

git blame src/CommonModules/ОбменССайтом/Ext/Module.bsl

Путь к файлу зависит от формата выгрузки, но принцип одинаков. Разбор регрессий и аудит изменений перестают зависеть от памяти конкретных людей.

Откатить задачу

Хранилище: вручную восстанавливать объекты из прежних версий, рискуя задеть чужие изменения.

Git: отменить конкретный коммит, сохранив историю:

git revert <хеш коммита>

Подводные камни 1С в Git

Честно о том, что не так гладко, как в классической разработке:

• Формы и служебные XML. Описание форм и метаданных хранится в XML, и при одновременной правке одной формы слияние бывает болезненным. Помогают короткие ветки и договорённость, кто правит общие формы.
• Двоичные части. Макеты и картинки сливать нельзя — их меняют по очереди.
• Сборка базы из исходников на большой конфигурации занимает время. Нужны стенды и автоматизация, иначе разработчики будут тратить часы на ожидание.
• Процесс важнее инструмента. Без правил ветвления и ревью Git превращается в то же хранилище, только с более сложными командами.

Варианты перехода

Второй вариант — хороший первый шаг: команда продолжает работать как привыкла, а в Git появляются история, ревью и сборка на каждый коммит. Сборка из исходников выполняется пакетным режимом конфигуратора:

1cv8 DESIGNER /F "C:\build\ib" /LoadConfigFromFiles "C:\repo\src" /UpdateDBCfg /Out build.log

После этого можно запускать проверки кода и автотесты — то, что в чистом хранилище организовать сложно. Подробнее о построении конвейера — в разделе DevOps для 1С.

Как перейти без остановки разработки

1. Аудит текущего процесса. Кто, как и с какой частотой выпускает изменения, где теряется время. Это база для оценки эффекта.
2. Выбор варианта. EDT или синхронизация хранилища, где будет удалённый репозиторий, кто его администрирует.
3. Правила ветвления. Основная ветка, ветка разработки, ветки задач, кто и как сливает. Чем проще, тем лучше.
4. Перенос истории. Выгрузка истории хранилища в Git, чтобы не потерять авторство и прошлые изменения.
5. Пилот на одной-двух задачах с частью команды.
6. Сборка и проверки. Автоматическая сборка на каждое слияние, проверка стандартов, затем — автоматическое тестирование.
7. Перевод всей команды и отключение записи в хранилище.

Техническая часть занимает дни, смена процесса — недели. Ориентир для оценки работ — 2 500 ₽/ч; точную оценку даю после аудита текущего процесса.

Git не ускоряет команду сам по себе. Он убирает искусственные очереди и даёт основу для автоматизации — а скорость появляется, когда на эту основу ставят сборку, ревью и тесты.

Чек-лист готовности к Git

• в команде больше двух-трёх разработчиков, и они мешают друг другу в хранилище;
• релизы частые, и нужно выпускать задачи независимо;
• есть требования к ревью кода и аудиту изменений;
• планируется автоматическая сборка и тестирование;
• рядом с вашей командой работают подрядчики, и нужно видеть их изменения.

Если совпадает хотя бы три пункта, переход окупится быстро. Если ни одного — хранилище пока справляется, и тратить ресурсы на смену инструмента рано.

Коротко

• Хранилище конфигурации ограничивает команду захватом объектов, отсутствием веток и слабой автоматизацией.
• Git даёт параллельную работу в ветках, прозрачную историю, безопасный откат и основу для CI/CD.
• У 1С в Git есть особенности: формы, двоичные макеты и время сборки — их закрывают правилами и автоматизацией.
• Мягкий старт — синхронизация хранилища в Git; полный вариант — разработка в 1С:EDT.
• Переход — это прежде всего смена процесса: правила ветвления, ревью, сборка и пилот.