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

Объединить конфигурации 1С проще всего штатным инструментом: Конфигуратор → меню Конфигурация → Сравнить, объединить с конфигурацией из файла…. Он открывает дерево объектов с различиями, где вы галочками выбираете, что перенести, а для спорных мест задаёте правило слияния.

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

Ниже — порядок действий, правила разрешения конфликтов в модулях и что проверить, прежде чем обновлять боевую базу.

Какие есть способы слияния и когда какой брать

Объединение всегда идёт в одну сторону: есть основная конфигурация (та, что открыта в Конфигураторе) и вливаемая — из файла .cf или из другой базы. Результат записывается в основную.

Способов три, и выбор зависит не от размера доработок, а от того, как часто вы это делаете и сколько человек в команде.

Дальше разберём каждый способ, начиная с самого частого — штатного механизма.

Подготовка: резервная копия и фиксация версий

Перед любым объединением сделайте резервную копию базы . Операция меняет корневую конфигурацию, и откатить её «по шагам» нельзя — только восстановлением из копии.

Копию снимают либо выгрузкой в .dt (Администрирование → Выгрузить информационную базу…), либо средствами СУБД для клиент-серверного варианта. Для большой базы бэкап СУБД быстрее и надёжнее.

Дальше зафиксируйте исходные данные, чтобы потом понять, что откуда пришло:

• 📌 запишите текущие релизы обеих конфигураций (Справка → О программе);
• 📌 выгрузите вливаемую конфигурацию в файл: в её базе Конфигурация → Сохранить конфигурацию в файл… (получится .cf);
• 📌 проверьте обе конфигурации на синтаксические ошибки до слияния, чтобы не тащить чужие проблемы.

Объединение штатным механизмом Конфигуратора

Основной сценарий. Откройте в Конфигураторе ту базу, куда вливаете изменения, и действуйте по шагам.

1. Меню Конфигурация → Сравнить, объединить с конфигурацией из файла…. Выберите подготовленный .cf. Если вливаете из живой базы — сначала выгрузите её в файл.
2. Откроется окно с деревом объектов. 1С покажет только различия: новые объекты, изменённые и удалённые.
3. Для каждого объекта в колонке режима задайте действие: взять из файла, объединить или не изменять. Галочка слева включает объект в обработку.
4. В настройках (кнопка с шестерёнкой или пункт меню окна) задайте приоритет — чья версия побеждает при совпадающих изменениях: основной конфигурации или файла.
5. Отдельно решите, разрешать ли удаление объектов основной конфигурации. По умолчанию удаление лучше не разрешать — так ничего не пропадёт случайно.
6. Нажмите Выполнить. Изменения внесутся в корневую конфигурацию, но ещё не в базу данных.

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

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

Как разрешать конфликты в модулях и формах

Конфликт возникает, когда один и тот же объект изменён и в основной конфигурации, и во вливаемой. С объектами (справочники, документы, реквизиты) всё решается выбором режима. Сложнее с модулями и формами.

Для модулей 1С умеет сливать не целиком, а по процедурам и функциям. В окне объединения у модуля можно раскрыть список методов и для каждого выбрать, из какой версии его взять. Там же доступен построчный просмотр — удобно, когда правки точечные.

Правила для модулей:

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

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

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

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

После разбора конфликтов не спешите закрывать окно. Пройдитесь по дереву ещё раз и убедитесь, что не осталось объектов с неразрешённым статусом — именно пропущенный конфликт потом всплывает ошибкой при проверке.

Пакетное слияние и автоматизация через командную строку

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

Сначала в обычном окне объединения настройте правила один раз и сохраните их в файл (в окне есть команда сохранения настроек в .xml). Дальше запускаете Конфигуратор из командной строки с ключом /MergeCfg, передавая .cf и этот файл настроек:

1cv8 DESIGNER /F "C:\base" /N "Администратор" /P "***" /MergeCfg "update.cf" "settings.xml" /UpdateDBCfg

Ключ /UpdateDBCfg сразу обновит конфигурацию базы данных после слияния. Точный набор параметров и их имена сверяйте через 1cv8 DESIGNER /? или документацию по пакетному режиму — не полагайтесь на память, если версия платформы отличается.

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

Слияние через Git и выгрузку конфигурации в файлы

Для командной разработки бинарный .cf неудобен — его не положить в систему контроля версий построчно. Решение — выгрузка конфигурации в текстовые файлы.

В Конфигураторе: Конфигурация → Выгрузить конфигурацию в файлы…. Получается дерево XML-файлов, по файлу на объект и отдельные файлы модулей. Это уже можно коммитить в Git и мёржить обычными средствами.

Рабочий цикл такой:

1. Каждый разработчик ведёт свою ветку, выгружает изменения в файлы и коммитит.
2. Слияние веток делает Git. Модули (текст) мёржатся построчно, как обычный код.
3. После мёржа загружаете результат обратно: Конфигурация → Загрузить конфигурацию из файлов….
4. Обновляете конфигурацию базы данных и тестируете.

Текстовый мёрж отлично работает для модулей и плохо — для форм и некоторых объектов, где структура лежит в XML и Git видит конфликт на уровне тегов. Такие конфликты всё равно придётся разбирать руками, часто прямо в Конфигураторе.

Пара практических деталей. Выгрузка в файлы тяжёлая: на крупной конфигурации это десятки тысяч файлов, поэтому выгружают в отдельный каталог и держат его под Git целиком, а саму .cf в репозиторий не кладут. И договоритесь в команде о едином формате выгрузки и версии платформы — файлы, выгруженные разными версиями, дают лишние различия на пустом месте и ломают мёрж.

Если команда работает в 1C:EDT, слияние через Git идёт нативно: EDT хранит проект в текстовом виде изначально, выгрузка/загрузка не нужна. Это самый удобный путь для постоянной параллельной разработки, но переход на EDT — отдельное решение, а не способ разового объединения.

Проверка и обновление базы после объединения

Слияние в Конфигураторе — это ещё не изменение в рабочей базе. Нужно довести дело до конца и убедиться, что ничего не сломалось.

Порядок финальных действий:

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

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

Отдельно проверьте права и интерфейсы, если в слиянии участвовали роли и подсистемы. После объединения зайдите под типичным пользователем и убедитесь, что доступ не расширился и не сузился сверх задуманного — это тот эффект, который легко пропустить на этапе разбора дерева.

Если после обновления база ведёт себя странно, проверьте её штатным механизмом: Администрирование → Тестирование и исправление. А при серьёзной проблеме — восстановитесь из той самой резервной копии, которую сняли на старте. Поэтому копия и делается первой.

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