Версионирование конфигурации 1С: от хранилища к Git

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

Если над одной конфигурацией работают несколько разработчиков, без версионирования правки затирают друг друга. Хранилище решает это захватом объектов и историей помещений, а связка с Git добавляет ветки, обзор изменений и привычные инструменты слияния. Разберём, что выбрать, как подключить и как разруливать конфликты.

Хранилище конфигурации или внешняя система контроля версий

Выбор зависит от размера команды и от того, нужны ли вам ветки и внешние инструменты.

Хранилище конфигурации — родной механизм платформы. Работает по принципу «один объект — один редактор»: пока разработчик держит объект захваченным, другой его изменить не может. Это исключает параллельные правки одного модуля, но и мешает вести несколько веток одновременно.

Git оперирует не объектами, а текстовыми файлами выгрузки. Даёт ветвление, pull-request-ревью, историю по строкам и сторонние клиенты. Платит за это необходимостью разрешать текстовые конфликты вручную.

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

Что подготовить до подключения

Версионирование требует одинакового окружения у всех участников, иначе выгрузки будут отличаться из-за версий платформы.

• 🧩 Единая версия платформы. Номер релиза платформы у всех разработчиков должен быть не ниже версии, в которой создано хранилище. Разнобой версий ведёт к ошибкам при подключении.
• 👤 Учётные записи. Для хранилища заведите отдельных пользователей — у каждого своя история помещений. Для Git настройте user.name и user.email в каждом рабочем окружении.
• 📁 Место под хранилище. Это каталог на файловом ресурсе или адрес сервера хранилища. Путь должен быть доступен всем на запись.
• 🔐 Права доступа . В хранилище права выдаёт администратор хранилища: кто может захватывать объекты, кто только читает. В Git доступ к репозиторию настраивается на стороне сервиса (GitLab, собственный сервер).

Для командной работы через файловый каталог хранилище кладут на общий сетевой ресурс. Для распределённых команд поднимают сервер хранилища конфигурации (служба 1C:Enterprise Configuration Repository Server), который слушает TCP-порт и отдаёт хранилище по адресу вида tcp://сервер:порт/имя.

Создание и подключение хранилища конфигурации

Хранилище создаётся один раз, затем к нему подключаются остальные разработчики.

Создание хранилища (делает один человек):

1. Откройте базу в режиме Конфигуратор.
2. Меню Конфигурация → Хранилище конфигурации → Создать хранилище.
3. Укажите путь к пустому каталогу (или адрес сервера хранилища).
4. Задайте имя и пароль администратора хранилища — это владелец, который дальше заводит пользователей.

После создания конфигурация становится привязанной к хранилищу: у объектов появляется признак «захвачен / не захвачен».

Подключение остальных участников:

1. Конфигурация → Хранилище конфигурации → Подключиться к хранилищу.
2. Укажите тот же путь или адрес tcp://....
3. Введите свои имя пользователя и пароль.

Ежедневная работа с объектами:

• 🔒 Захват — Хранилище конфигурации → Захватить в хранилище на объекте или ветке дерева. Объект становится вашим для редактирования.
• 📤 Помещение — Поместить в хранилище фиксирует изменения с комментарием. Комментарий виден в истории.
• 📥 Обновление — Обновить конфигурацию из хранилища подтягивает чужие помещённые изменения в вашу базу.
• 📜 История — Хранилище конфигурации → История хранилища показывает все версии с авторами и комментариями.

Администрирование и права. Администратор хранилища заводит пользователей и раздаёт права на объекты: кому разрешён захват, а кому доступно только чтение. Там же решается типичная ситуация, когда объект остался захваченным уволившимся или отсутствующим сотрудником. Администратор может принудительно отменить чужой захват через управление хранилищем — но только убедившись, что человек не держит в работе несохранённые правки, иначе они потеряются.

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

Пакетные операции с хранилищем доступны и из командной строки — удобно для серверов сборки:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER ^
  /F "D:\base" /N "Админ" /P "пароль" ^
  /ConfigurationRepositoryF "\\server\repo" ^
  /ConfigurationRepositoryN "builder" ^
  /ConfigurationRepositoryP "пароль_хранилища" ^
  /ConfigurationRepositoryUpdateCfg

Параметр /ConfigurationRepositoryUpdateCfg обновляет конфигурацию из хранилища, /ConfigurationRepositoryDumpCfg — выгружает из хранилища файл .cf. Пароли в командной строке видны в списке процессов — на серверах сборки используйте защищённые переменные окружения, а не открытый текст в .bat.

Выгрузка конфигурации в файлы и работа через Git

Git не умеет работать с бинарным .cf, поэтому конфигурацию выгружают в дерево текстовых файлов. Эта возможность встроена в Конфигуратор актуальных релизов платформы 8.3.

Интерактивно:

1. Конфигурация → Выгрузить конфигурацию в файлы.
2. Укажите каталог — он и станет рабочей копией репозитория Git.
3. Обратная операция — Загрузить конфигурацию из файлов.

Из командной строки (для автоматической сборки и хуков коммита):

1cv8.exe DESIGNER /F "D:\base" /N "Админ" /P "пароль" ^
  /DumpConfigToFiles "D:\repo\src"

1cv8.exe DESIGNER /F "D:\base" /N "Админ" /P "пароль" ^
  /LoadConfigFromFiles "D:\repo\src"

Дальше это обычный Git. В каталоге выгрузки инициализируйте репозиторий и зафиксируйте первый коммит:

cd D:/repo
git init
git add src
git commit -m "Исходная выгрузка конфигурации"

Форма работы: разработчик выгружает конфигурацию в файлы, коммитит изменения в свою ветку, при необходимости делает слияние. Перед загрузкой обратно в базу делает git pull, затем /LoadConfigFromFiles и обновление конфигурации базы данных.

Отдельная тема — перенос истории хранилища в Git. Если вы годами вели хранилище, его историю помещений можно перелить в Git покоммитно, сохранив авторов и комментарии. Для этого применяют инструменты экосистемы OneScript — gitsync для синхронизации истории и precommit1c для корректной обработки выгрузки на хуке коммита. Это внешние открытые утилиты; точный синтаксис смотрите в их документации, он меняется между версиями.

Версионирование в 1С:EDT

1С:EDT (среда разработки на базе Eclipse) хранит проект конфигурации в текстовом виде изначально — отдельная выгрузка не нужна, Git работает с рабочим каталогом проекта напрямую.

Порядок настройки:

1. Импортируйте конфигурацию в EDT: из .cf, из информационной базы или из каталога выгрузки.
2. Подключите систему контроля версий через встроенный в Eclipse EGit: правый клик по проекту → команды Team (Team → Share Project), выберите Git.
3. Дальше — привычный цикл: правки → Commit → Push, переключение и создание веток средствами EGit.

Преимущество EDT в том, что сравнение и слияние идут на уровне текстового проекта, а среда показывает изменения построчно без отдельного шага выгрузки. Для командной разработки с ветками это удобнее, чем ручная выгрузка из Конфигуратора.

Типичный командный цикл в EDT с ветками выглядит так:

1. От основной ветки создаёте ветку под задачу (Team → Switch To → New Branch).
2. Правите конфигурацию, фиксируете коммиты по ходу работы.
3. Выгружаете ветку на сервер (Push) и оформляете запрос на слияние в вашем сервисе Git.
4. После ревью сливаете ветку в основную и переносите изменения в информационную базу.

Перенос из проекта EDT в рабочую базу делается командой выгрузки конфигурации из проекта и последующим обновлением конфигурации базы данных — так же, как при работе через Конфигуратор.

При переходе между Конфигуратором и EDT учитывайте, что синхронизация изменений туда-обратно требует времени на индексацию проекта, особенно на крупных конфигурациях. Это нормальное поведение среды, а не ошибка.

Слияние изменений и разрешение конфликтов

Конфликты в хранилище и в Git возникают по-разному, поэтому и разрешаются разными средствами.

В хранилище конфигурации прямых конфликтов правок почти не бывает: пока объект захвачен одним разработчиком, другой его не изменит. Конфликт возможен при сравнении и объединении конфигураций — например, когда вы накатываете обновление поставщика поверх своих доработок. Тогда помогает встроенное сравнение и объединение конфигураций (Конфигурация → Сравнить, объединить с конфигурацией из файла): платформа показывает отличия по объектам и даёт выбрать, какую версию взять.

В Git конфликт — это пересечение правок в одних и тех же строках выгрузки при слиянии веток. Разрешается стандартно:

1. git merge (или слияние pull-request) сообщает о конфликтных файлах.
2. Откройте файл: конфликтные участки помечены маркерами <<<<<<<, =======, >>>>>>>.
3. Оставьте нужный вариант, уберите маркеры.
4. git add разрешённого файла и завершите слияние коммитом.

Для выгрузки конфигурации важно, что текст объектов разбит на много мелких файлов — конфликт обычно локализуется в одном модуле, а не во всей конфигурации. После разрешения конфликта обязательно загрузите итог обратно в базу (/LoadConfigFromFiles) и проверьте, что конфигурация собирается без ошибок.

Практики, которые снижают число конфликтов:

• 🌿 Короткие ветки. Чем дольше ветка живёт в отрыве от основной, тем болезненнее слияние.
• 💬 Понятные комментарии коммитов и помещений. История должна читаться без расшифровки.
• 🧪 Проверка сборки после слияния. Загрузите конфигурацию в базу и убедитесь, что она обновляется без ошибок, прежде чем двигаться дальше.
• 👥 Договорённость о зонах ответственности. Если двое правят один модуль, согласуйте порядок, а не надейтесь на автослияние.

Частые вопросы