← На главную

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

Разберем, почему стандартный инструмент сравнения и объединения в классическом Конфигураторе не решает эту задачу «из коробки», а также рассмотрим проверенные способы выполнения трехстороннего слияния (3-way merge) для расширений конфигурации.

Почему в Конфигураторе 1С не работает трехстороннее объединение расширений?

Проанализируем архитектурные ограничения платформы 1С:Предприятие. В стандартном Конфигураторе механизм выявления дважды измененных объектов тесно связан с подсистемой поставки и поддержки. При обновлении типовых конфигураций платформа опирается на конфигурацию поставщика, которая выступает общим предком (Base/Ancestry). Зная предка, платформа может сопоставить текущую конфигурацию базы и файл обновления, выделив конфликты.

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

Даже если в параметрах Конфигуратора подключена внешняя программа трехстороннего слияния (например, KDiff3 или P4Merge), платформа автоматически вызывает ее в трехстороннем режиме только для конфигураций на поддержке. При сравнении расширений во внешнюю утилиту передаются только два файла, чего для полноценного разрешения конфликтов недостаточно.

Решение 1. Использование 1C:EDT (Enterprise Development Tools)

Рассмотрим наиболее современный и «нативный» подход к трехстороннему слиянию расширений. Среда разработки 1C:EDT построена на базе Eclipse и использует Git в качестве базовой системы контроля версий. В ней задача поиска дважды измененных объектов решается штатно:

1. Проекты расширений в EDT хранятся в виде декомпозированных текстовых файлов и XML-структур.
2. Базовое состояние расширения (А) фиксируется в ветке репозитория общим предком.
3. Доработки программистов (Б и В) ведутся в отдельных ветках.
4. При слиянии веток Git автоматически определяет общего предка и запускает процедуру 3-way merge.
5. Если один и тот же модуль или реквизит был изменен параллельно, EDT выводит визуальный редактор конфликтов, отображая три панели: предка (Base), локальные изменения (Mine) и входящие изменения (Theirs), а также результирующий блок.

Решение 2. Выгрузка в исходники и слияние через Git

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

1. Выполним пакетную выгрузку исходной версии расширения (А) в файлы с помощью параметров командной строки Конфигуратора:
   Скопировать код

   
   1cv8.exe DESIGNER /IBConnectionString "..." /DumpConfigToFiles "C:\Repo\Extension" -Extension "МоеРасширение"
   

2. Инициализируем репозиторий Git в папке C:\Repo\Extension и создадим базовый коммит для состояния А.
3. Создадим ветку feature/programmer1, выгрузим туда состояние Б и закоммитим изменения.
4. Вернемся к коммиту А, создадим ветку feature/programmer2, выгрузим туда состояние В и выполним коммит.
5. Выполним слияние веток:
   Скопировать код

   
   git checkout feature/programmer1
   git merge feature/programmer2
   

6. В случае конфликтов Git выделит именно дважды измененные файлы и строки модулей. Разрешим конфликты вручную или с помощью любого настроенного графического инструмента (KDiff3, P4Merge, VS Code).
7. Загрузим полученный результат обратно в информационную базу:
   Скопировать код

   
   1cv8.exe DESIGNER /IBConnectionString "..." /LoadConfigFromFiles "C:\Repo\Extension" -Extension "МоеРасширение"
   

Решение 3. Трехстороннее сравнение каталогов внешними утилитами

Посмотрим на сценарий, когда Git на проекте не развернут, но требуется быстро локализовать дважды измененные объекты. Для этого используем внешние программы, умеющие выполнять 3-Way Merge на уровне каталогов (например, KDiff3, Beyond Compare или P4Merge):

1. Выгрузим состояние расширения А в каталог C:\Merge\Base через команду пакетного режима /DumpConfigToFiles -Extension <ИмяРасширения> или через меню Конфигуратора Конфигурация - Выгрузить конфигурацию в файлы... (предварительно открыв расширение).
2. Аналогично выгрузим расширение Б в каталог C:\Merge\Mine.
3. Выгрузим расширение В в каталог C:\Merge\Theirs.
4. Запустим утилиту слияния каталогов и укажем три пути:
   1. Base: C:\Merge\Base (исходное состояние А);
   2. First / Mine: C:\Merge\Mine (доработки первого программиста Б);
   3. Second / Theirs: C:\Merge\Theirs (доработки второго программиста В).
5. Программа автоматически отфильтрует неизмененные файлы и выделит цветом конфликты — файлы, которые изменились одновременно в папках Mine и Theirs относительно Base. Это и есть искомые дважды измененные объекты.
6. Объединив конфликтные модули и XML-описания метаданных, сохраним результат в отдельный каталог и загрузим его в базу через /LoadConfigFromFiles.

Решение 4. Аналитический метод внутри Конфигуратора (попарные отчеты)

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

1. Откроем расширение А и выполним сравнение с расширением Б (Действия - Сравнить с расширением из файла...).
2. Нажмем кнопку Отчет о сравнении конфигураций и сохраним текстовый отчет со списком всех измененных объектов ветки Б.
3. Повторим операцию: сравним расширение А с файлом расширения В и сформируем второй отчет со списком измененных объектов ветки В.
4. Сравним два полученных списка (например, в обычном текстовом редакторе или через Excel). Пересечение этих двух списков даст точный перечень объектов, которые правили оба программиста.
5. При финальном объединении версий Б и В в Конфигураторе особое внимание уделяем только объектам из полученного списка пересечений, объединяя их свойства и модули вручную.