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

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

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

Ниже разобраны все три подхода с конкретными шагами настройки, проверкой результата и ограничениями. Инструкции ориентированы на платформу 1С:Предприятие 8.3 и типовые конфигурации на базе БСП (УТ, ERP, Бухгалтерия, ЗУП).

Определяемся с типом версионирования

Главная ошибка на старте — путать версионирование кода и версионирование данных. Хранилище конфигурации фиксирует изменения, которые вносят разработчики в структуру метаданных, модули и формы. Оно не сохраняет ни одного пользовательского документа. Подсистема «Версионирование объектов», наоборот, работает только с данными: документами, элементами справочников, — и ничего не знает о коде.

Третий вариант — выгрузка конфигурации в файлы XML и работа с Git. Он нужен командам, которые используют CI/CD, автоматические тесты и код-ревью. Для небольшой команды из одного-двух разработчиков Git часто избыточен: хранилище конфигурации покрывает их задачи проще и дешевле по трудозатратам.

Настраиваем хранилище конфигурации

Хранилище создаётся из конфигуратора пользователем с правами администратора при монопольном доступе к базе. Путь к хранилищу должен быть доступен всем разработчикам — обычно это сетевая папка на сервере. Учтите: при создании хранилища текущая конфигурация базы данных становится первой версией, поэтому убедитесь, что база находится в рабочем, стабильном состоянии.

1. 1
   Сделайте выгрузку базы в файл .dt через конфигуратор (Администрирование → Выгрузить информационную базу).
2. 2
   Создайте пустую сетевую папку для хранилища с правами на чтение и запись для всех разработчиков.
3. 3
   Откройте конфигуратор в монопольном режиме, меню Конфигурация → Хранилище конфигурации → Создать хранилище.
4. 4
   Укажите путь к папке, задайте логин и пароль администратора хранилища.
5. 5
   Добавьте пользователей хранилища: Конфигурация → Хранилище конфигурации → Администрирование → Пользователи.
6. 6
   Разработчики подключаются через Конфигурация → Хранилище конфигурации → Подключиться и захватывают объекты перед изменением.

После подключения к хранилищу режим работы меняется: чтобы изменить объект, его нужно захватить (checkout), после правок — поместить обратно (checkin) с комментарием. Комментарии обязуйте писать осмысленные: «Исправлен расчёт скидки в документе РеализацияТоваровУслуг», а не «правки» или «fix». Именно по ним вы будете искать нужную версию через полгода.

Для обновления рабочей базы из хранилища используйте команду «Обновить конфигурацию базы данных из хранилища». Это безопаснее, чем прямая загрузка cf-файлов, потому что сохраняется соответствие между версией хранилища и состоянием базы.

Включаем версионирование объектов для пользовательских данных

В типовых конфигурациях на базе БСП (Управление торговлей, ERP, Бухгалтерия предприятия, ЗУП) подсистема версионирования объектов уже встроена, её нужно только включить. Перейдите в раздел «НСИ и администрирование» (или «Администрирование») → «Общие настройки» → «Версионирование объектов» и установите флаг «Версионирование объектов».

Далее нажмите «Настроить» и отметьте типы объектов, для которых нужна история. Обычно это ключевые документы (реализация, поступление, платёжные поручения) и критичные справочники (контрагенты, номенклатура, договоры). Не включайте версионирование для всего подряд: каждая версия хранится в базе, и на активно редактируемых документах объём базы начнёт заметно расти.

Для каждого типа объекта можно выбрать режим: «Версионировать при записи» или «Версионировать при проведении». Для документов чаще выбирают версионирование при проведении — тогда история не засоряется промежуточными сохранениями черновиков. Также настройте срок хранения версий: бессрочное хранение оправдано только для юридически значимых объектов.

Проверьте результат: откройте любой документ версионируемого типа, измените реквизит и проведите. Затем в меню документа выберите «Ещё» → «История изменений» (или «Версии объекта»). Должна появиться запись с датой, автором и возможностью сравнить версии или открыть любую из них.

Настраиваем Git для конфигурации 1С

Работа с Git возможна двумя путями: через 1C:Enterprise Development Tools (EDT), где интеграция с Git встроена, или через выгрузку конфигурации в XML-файлы из конфигуратора с последующим коммитом. EDT — предпочтительный вариант для новых проектов: проект в EDT изначально хранится в файловом формате, совместимом с системами контроля версий.

Для классического конфигуратора используется выгрузка в файлы конфигурации. Команда пакетного режима выглядит так:

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"C:\bases\mybase" /N"Администратор" /DumpConfigToFiles "C:\repo\myconfig" -Format Hierarchical

Выгрузку обычно автоматизируют: скрипт запускается по расписанию или после помещения изменений в хранилище, а затем выполняет git add, commit и push. Прямое редактирование XML-файлов вне конфигуратора недопустимо — структура файлов сложная, и ручные правки почти гарантированно приведут к невозможности загрузки конфигурации обратно.

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

Регламентные задачи и обслуживание

Версионирование объектов создаёт регламентное задание на запись версий — проверьте, что оно активно и выполняется без ошибок (Администрирование → Регламентные и фоновые задания). Если задание отключено или падает с ошибкой, версии перестанут создаваться, хотя интерфейс будет выглядеть включённым.

Настройте периодическую очистку устаревших версий. В настройках версионирования укажите срок хранения, например 365 дней для документов и бессрочно — только для действительно критичных объектов. Дополнительно раз в квартал проверяйте размер таблицы версий: в клиент-серверном варианте это можно сделать средствами СУБД.

Для хранилища конфигурации полезно периодически делать копию папки хранилища и проверять целостность: Конфигурация → Хранилище конфигурации → Администрирование → Проверка целостности. Повреждённое хранилище восстанавливается только из копии — встроенных средств ремонта нет.

Безопасность и границы самостоятельной настройки

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

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

Часто задаваемые вопросы