Как найти различия между двумя конфигурациями 1С

Две базы разошлись: где-то дорабатывали под клиента, где-то накатывали обновление, и теперь никто не помнит, чем конфигурации отличаются. Самый быстрый ответ — штатный инструмент: в Конфигураторе откройте Конфигурация → Сравнить конфигурации…, выберите две конфигурации (основную, базы данных, поставщика или из файла) и получите дерево различий. Если нужно сравнить два отдельных файла .cf или держать историю изменений — подойдут выгрузка в файлы с diff-утилитой и Git.

Ниже — четыре рабочих способа сравнить конфигурации 1С (от штатного отчёта до автоматизации), таблица, какой из них когда применять, и разбор того, что делать с макетами и внешними обработками. Всё для платформы 8.3 с интерфейсом «Такси».

Что именно сравнивают и что покажет результат

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

• 🗂️ Основная конфигурация — та, что вы правите в Конфигураторе.
• 💾 Конфигурация базы данных — активная, по которой реально работают пользователи. Расходится с основной, пока вы не нажали «Обновить конфигурацию базы данных».
• 🏭 Конфигурация поставщика — эталон от разработчика (типовая БП, ЗУП, УТ), если база на поддержке.
• 📄 Конфигурация из файла — выгрузка .cf, присланная коллегой или снятая с другой базы.

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

Сравнение штатными средствами Конфигуратора

Это основной способ, когда обе конфигурации доступны в одной базе или одна из них лежит в файле .cf.

Сравнить две конфигурации внутри базы

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

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

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

Сравнить с конфигурацией из файла

Если вторая конфигурация пришла файлом .cf:

1. Конфигурация → Сравнить, объединить с конфигурацией из файла….
2. Укажите путь к .cf.
3. Платформа построит то же дерево различий, но добавит галочки для объединения.

Сравнить с конфигурацией поставщика

Когда база на поддержке, различия с типовой смотрят через Конфигурация → Поддержка → Настройка поддержки…. Напротив изменённых объектов стоит пометка «Изменён», по ней видно, что отступило от эталона. Это и есть ответ на вопрос «что у нас допилено относительно типовой».

Сохранить отчёт о сравнении

Чтобы отдать различия коллеге или приложить к задаче:

• В окне сравнения — команда формирования отчёта (в командной панели окна различий).
• Отчёт сохраняется как текст или табличный документ .mxl.
• В настройках отчёта можно оставить только изменённые объекты и выбрать уровень детализации — вплоть до построчных различий в модулях.

Как сравнить два файла .cf между собой

Штатный диалог сравнивает текущую конфигурацию с файлом, но не два файла напрямую. Приём:

1. Создайте пустую файловую базу .
2. Конфигурация → Загрузить конфигурацию из файла… — загрузите первый .cf.
3. Конфигурация → Сравнить, объединить с конфигурацией из файла… — укажите второй .cf.
4. Смотрите дерево различий, объединение не выполняйте.

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

Сравнение через выгрузку в файлы и diff-утилиты

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

В Конфигураторе: Конфигурация → Выгрузить конфигурацию в файлы… — укажите пустой каталог. Платформа разложит объекты по папкам, модули — в .bsl (или .txt в старых релизах), формы и макеты — в XML.

Сделайте это для обеих конфигураций в два разных каталога и сравните их любой diff-утилитой для папок:

• KDiff3, WinMerge, Beyond Compare — сравнение каталогов целиком, с подсветкой изменённых строк в модулях.
• Результат читается как обычный diff: что добавлено, что удалено, что переписано.

Этот же приём лежит в основе «внешнего» сравнения, когда штатного отчёта не хватает: вся логика модулей оказывается в текстовом виде, и к ней применимы привычные инструменты сравнения кода.

Сравнение истории изменений через Git

Если сравнивать приходится регулярно — удобнее не ловить два состояния вручную, а хранить конфигурацию в системе контроля версий. Тогда «сравнить две версии» превращается в обычный git diff.

Схема рабочая такая:

1. Выгружаете конфигурацию в файлы (вручную или командой пакетного режима — см. раздел про автоматизацию).
2. Кладёте каталог выгрузки под Git и делаете коммит на каждую значимую правку.
3. Любые две точки истории сравниваете командой git diff <коммит1> <коммит2> или через графический клиент.

Для связки 1С и Git чаще всего берут gitsync и precommit1c (инструменты на OneScript): они приводят выгрузку к стабильному для diff виду и упрощают коммиты. Это сторонние проекты сообщества, не входят в поставку платформы.

Отдельно стоит 1C:Enterprise Development Tools (EDT) — среда разработки, где проект изначально хранится как текстовые файлы и дружит с Git «из коробки». В EDT сравнение и объединение версий встроены (Compare With на объекте или проекте), поэтому для Git-процесса EDT — самый естественный вариант.

Какой способ выбрать: сравнение методов

Коротко — чем отличаются подходы и когда какой брать.

На практике: один раз посмотреть — Конфигуратор; разобраться в коде по-крупному — выгрузка в файлы; вести разработку командой — Git или EDT.

Сравнение макетов и внешних обработок

С модулями и реквизитами всё наглядно, а вот два случая требуют отдельного подхода.

Макеты (табличные документы). В дереве различий платформа чаще показывает только факт «макет изменён», без детализации по ячейкам. Чтобы понять, что именно поправили в печатной форме, откройте макет в каждой конфигурации, сохраните как табличный документ .mxl в файл и сравните два файла визуально. Схемы компоновки данных в макетах лучше читаются через выгрузку в файлы — там СКД лежит отдельным XML.

Внешние отчёты и обработки (.erf, .epf). Это самостоятельные файлы, их нет в дереве конфигурации. Чтобы сравнить две версии обработки, выгрузите каждую в файлы (EDT умеет это для внешних отчётов и обработок) и сравните каталоги diff-утилитой. Если нужен только встроенный код — откройте обе обработки в Конфигураторе и сравните тексты модулей вручную или через выгрузку модуля в текст.

Сравнение расширений конфигурации

Расширения (появились в платформе 8.3.6, хранятся в файлах .cfe) — отдельные от основной конфигурации объекты, и сравнивают их своими путями.

Открыть список расширений: Конфигурация → Расширения конфигурации. Каждое расширение — это самостоятельная конфигурация со своим деревом объектов. Два частых сравнения:

• Расширение против основной конфигурации — чтобы понять, какие объекты расширение заимствует и что в них переопределяет. Заимствованные объекты в дереве расширения помечены особым значком.
• Две версии одного расширения (например, до и после доработки) — выгрузите каждую в файлы через тот же Выгрузить конфигурацию в файлы…, предварительно сделав расширение активным, и сравните каталоги diff-утилитой.

Чтобы сравнить два файла .cfe между собой, загрузите их в тестовую базу (Загрузить конфигурацию из файла… в контексте расширения) и действуйте как с обычными конфигурациями — через дерево различий.

Автоматизация сравнения в CI/CD

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

Опора — пакетный режим Конфигуратора. Основные команды:

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F "C:\base" ^
  /DumpConfigToFiles "C:\out\base_A"

"...\1cv8.exe" DESIGNER /F "C:\base" /DumpCfg "C:\out\base.cf"

• /DumpConfigToFiles — выгрузка конфигурации в каталог текстовых файлов.
• /DumpCfg — выгрузка в единый файл .cf.
• Обратная загрузка — /LoadConfigFromFiles и /LoadCfg соответственно.

Типовой конвейер в Jenkins или GitLab CI выглядит так:

1. Шаг выгружает конфигурацию каждой базы в файлы командой DESIGNER /DumpConfigToFiles.
2. Выгрузка коммитится в Git.
3. git diff или отдельный шаг сравнения формирует отчёт о различиях между веткой и эталоном.
4. Отчёт прикладывается к сборке; при расхождениях вне ожидаемого сборка помечается как требующая внимания.

Для оркестрации этих шагов сообщество использует те же gitsync и связку с Vanessa Automation (для тестов), но ядро — всегда пакетные команды платформы, показанные выше.

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