Хранилище конфигурации 1С или GIT: как выбрать инструмент и настроить процесс разработки

В современной разработке на платформе 1С:Предприятие вопрос выбора системы контроля версий (VCS) стоит особенно остро. С одной стороны, мы имеем проверенное годами Хранилище конфигурации, которое интегрировано в конфигуратор «из коробки». С другой — Git, мировой стандарт разработки ПО, предлагающий гибкость, ветвление и возможности автоматизации. Разберем подробно, какой инструмент лучше подходит под ваши задачи, и как организовать рабочий процесс в каждом из случаев.

Сравнение фундаментальных подходов: Пессимистическая vs Оптимистическая блокировка

Для начала проанализируем ключевое различие в логике работы этих систем. В 1С-хранилище используется пессимистическая блокировка (захват объекта). Это означает, что если один разработчик захватил ОбщийМодуль, второй не сможет внести в него изменения, пока первый их не применит. Это исключает конфликты при слиянии, но сильно тормозит параллельную разработку в больших командах.

Git использует оптимистический подход. Несколько разработчиков могут одновременно править один и тот же файл. Конфликты решаются на этапе слияния (Merge). Рассмотрим подробнее, почему для 1С это стало возможным: благодаря механизму выгрузки конфигурации в файлы XML, Git может сравнивать изменения в текстовом виде и автоматически объединять их, если правки были сделаны в разных частях модуля.

Преимущества и недостатки Хранилища конфигурации

Выясним причины, по которым многие команды до сих пор предпочитают классическое Хранилище:

1. Простота входа: Не нужно устанавливать сторонний софт, настраивать веб-серверы или изучать консольные команды. Достаточно пары кликов в конфигураторе.
2. Работа с обычными формами: Для конфигураций на базе 1С:УПП или старых самописок Хранилище — единственный адекватный выбор, так как 1С:EDT (основной мост к Git) не поддерживает визуальный редактор обычных форм.
3. Скорость для мелких правок: Если нужно исправить одну опечатку, процесс «захватил — поправил — поместил» занимает секунды.

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

Преимущества использования Git в 1С

Проанализируем возможности, которые открываются при переходе на Git, особенно при использовании 1С:EDT или инструментов автоматизации:

• Ветвление (Branching): Под каждую задачу (заявку) создается отдельная ветка. Это позволяет вести «творческий поиск», экспериментировать с кодом, не ломая основную конфигурацию. Если прилетает срочный баг, вы просто переключаетесь на ветку master, правите ошибку и возвращаетесь к своей задаче.
• Параллельная разработка: Больше нет ситуации «отдайте корень конфигурации!». Десятки разработчиков могут одновременно менять структуру метаданных.
• История и анализ: Инструменты типа git blame позволяют мгновенно увидеть, кто и когда изменил конкретную строку кода три года назад и к какой задаче в Jira это относилось.
• CI/CD (Continuous Integration/Continuous Deployment): Вы можете настроить автоматический запуск тестов (например, через Vanessa-Automation) и проверку кода (SonarQube) при каждом пуше в репозиторий.

Сценарий 1: Организация работы через конфигуратор и Git (Manual Workflow)

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

1. Выполняем доработки в своей локальной базе.
2. Используем команду Конфигурация — Выгрузить конфигурацию в файлы.
3. В консоли Git или через GUI-клиент (например, SourceTree или GitKraken) фиксируем изменения (commit).
4. Для получения чужих изменений выполняем pull, а затем в конфигураторе выбираем Загрузить конфигурацию из файлов.

Важный нюанс: Начиная с платформы 8.3.10, выгрузка стала инкрементальной. Если использовать параметры командной строки, 1С выгрузит только те объекты, которые изменились. Это сокращает время процесса с 20 минут (для ERP) до 1-2 минут.

Пример команды для автоматизации выгрузки через cmd:

"C:\Program Files\1cv8\8.3.x.x\bin\1cv8.exe" DESIGNER /F "D:\Bases\MyBase" /N "Admin" /P "Pass" /DumpConfigToFiles "D:\GitRepo\src" -Update

Сценарий 2: Использование 1С:EDT (Native Git)

Рассмотрим более современный вариант. 1С:Enterprise Development Tools (EDT) — это IDE на базе Eclipse, где работа с Git является нативной. Здесь нет понятия «выгрузка в файлы» как отдельного мучительного шага. Вы просто правите код, и EDT сама понимает, какие файлы изменились.

В этом сценарии процесс слияния веток (Merge) становится визуальным и удобным. Вы видите конфликты в коде и можете выбрать, какой вариант оставить. Это идеальный вариант для проектов на Управляемых формах.

Сценарий 3: Гибридная схема (Хранилище + Git)

Разберем ситуацию, когда команда привыкла к Хранилищу, но руководство хочет внедрить CI/CD и контроль качества. Для этого применяется инструмент gitsync (на базе OneScript). Процесс выглядит так:

1. Разработчики по-прежнему работают в Хранилище конфигурации 1С.
2. Специальный сервер по расписанию (например, раз в 15 минут) забирает новые версии из Хранилища и делает автоматический коммит в Git.
3. В Git-репозитории запускаются автоматические проверки кода и сборка дистрибутивов.

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

Рекомендации по выбору

Посмотрим на ситуацию со стороны масштаба проекта и типа конфигурации:

Выбирайте Хранилище, если:

• В команде 1-2 человека.
• Конфигурация на обычных формах (УПП 1.3, КА 1.1).
• Нет времени на освоение новых инструментов и настройку серверов.

Переходите на Git (EDT), если:

• В команде более 5 разработчиков.
• Проект на управляемых формах (ERP, БП 3.0, ЗУП 3.1).
• Требуется автоматизация тестирования и строгий контроль качества кода (Code Review).
• Нужно вести несколько параллельных веток разработки (например, поддержка текущего релиза и разработка нового функционала).

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