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

В статье подготовим окружение, импортируем существующую конфигурацию в EDT‑проект, настроим .gitignore и Git LFS под структуру EDT, организуем веточную модель для команды и разберём решение типичных конфликтов в XML‑метаданных.

Что понадобится

Минимальный набор инструментов выглядит так. Сама среда — 1С:EDT версии 2024.1 или новее (старые версии работают, но в новых заметно лучше скорость индексации и поддержка крупных конфигураций). Git для Windows или Linux — обязательно. Git LFS — для бинарных файлов внутри конфигурации (шаблоны, макеты, драйверы оборудования). Удалённый репозиторий — GitLab, GitHub, Gitea, локальный Gitolite, что угодно с поддержкой LFS.

Опционально — утилита ring, которая ставится вместе с EDT и позволяет работать с проектом из командной строки (миграции, импорт, проверка версий платформы).

Проверить её доступность:

ring --version
ring edt platform-versions

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

Импорт существующей конфигурации в EDT

Открываем 1С:EDT, переходим в перспективу «1С:Предприятие». Из меню Файл → Импорт → 1С:Предприятие → Конфигурация и расширения из информационной базы. В мастере выбираем подключённую информационную базу, указываем имя проекта (полезно сразу дать осмысленное — crm-production или accounting-dev, а не дефолтное Project), указываем версию платформы и каталог проекта.

Импорт работает не моментально, для типовой ERP это десятки минут, EDT построчно разбирает метаданные и раскладывает их по файловой структуре. Результат — каталог проекта со структурой:

crm-production/
├── .project
├── .settings/
└── src/
    ├── Configuration/
    │   ├── Configuration.mdo
    │   ├── ConfigurationProperties.xml
    │   └── ParentConfigurations/
    ├── Catalogs/
    ├── Documents/
    ├── CommonModules/
    │   └── ОбщегоНазначения/
    │       ├── ОбщегоНазначения.mdo
    │       └── Module.bsl
    └── ...

Каждый модуль — это .bsl файл (обычный текст), каждый объект метаданных — .mdo плюс XML с описанием, формы — отдельные XML‑файлы. С этим уже можно работать в Git нормально: построчный diff, merge, blame, all the good things.

Настройка.gitignore под структуру EDT

Дефолтный .gitignore от EDT минимальный, и его имеет смысл сразу расширить. Базовый набор, который закрывает основные источники мусора в репозитории:

# Eclipse / EDT служебное
.metadata/
.settings/
bin/
*.tmp

# Импорт-экспорт служебные
DumpFilesIndex.txt
ConfigDumpInfo.xml

# Конфигурации поставщиков — не нужны в Git разработчика
src/Configuration/ParentConfigurations.bin
src/Configuration/ParentConfigurations/**

# Локальные базы разработчика
*.1CD
*.CD

# Кэш-файлы платформы
*.dt.bak

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

Файл .gitignore коммитим в корень проекта — он должен попасть в репозиторий и быть одинаковым у всей команды.

Git LFS для бинарных файлов

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

Установка Git LFS и настройка отслеживания:

# установка (Windows — скачать с git-lfs.com, Linux — apt/yum)
git lfs install

# в корне проекта
git lfs track "*/Ext/Template.bin"
git lfs track "*/Ext/Module.bin"
git lfs track "*/Picture.png"
git lfs track "src/CommonTemplates/**/Template.bin"

После этого создаётся файл .gitattributes в корне проекта — его тоже коммитим. Все указанные файлы будут храниться в LFS‑хранилище, а в Git‑репозитории останутся только указатели на них.

Удалённый репозиторий должен поддерживать LFS — у GitHub и GitLab это включено по умолчанию, для Gitea и Gitolite нужно явно настроить хранилище.

Подключение к удалённому репозиторию

Базовая настройка Git в EDT делается через Окно → Параметры → Групповая разработка → Git → Конфигурация → Настройки пользователя. Указываются user.name и user.email — те же, что в системе планирования задач, чтобы коммиты корректно атрибутировались автору.

Связывание проекта с удалённым репозиторием через перспективу Git: Окно → Открыть перспективу → Git, потом Клонировать репозиторий или Добавить существующий репозиторий в зависимости от того, есть уже репозиторий или нет.

Первый push крупной конфигурации может занять часы (особенно через корпоративный VPN с медленным каналом) — это нормально, и имеет смысл делать его с локальной машины с быстрым интернетом, а не с прод‑сервера.

Стратегия веток для команды

Минимальная рабочая модель — две долгоживущие ветки и feature‑ветки:

• main (или master) — то, что выкатывается в продакшен;

• develop — то, что собирается в следующий релиз;

• feature/имя-задачи — короткоживущие ветки для конкретных задач.

Цикл такой: разработчик берёт задачу, делает git checkout -b feature/JIRA-1234-разрешение-возвратов из develop, работает, коммитит, открывает merge request обратно в develop. После проверки и code review merge request вливается, ветка удаляется.

Для команды до десяти разработчиков такой схемы достаточно. Если команда крупнее или нужна параллельная работа над несколькими релизами одновременно, добавляются release/* и hotfix/* ветки по канону Git Flow.

А еще у каждой ветки своя информационная база. То есть разработчик, переключившись с feature/A на feature/B, должен пересобрать конфигурацию в свою рабочую базу (через «Команды разработчика» → «Загрузить конфигурацию в базу»). EDT поддерживает связывание нескольких баз с одним проектом через «Панель приложений».

Решение конфликтов в XML‑метаданных

Главная боль командной разработки в EDT+Git — конфликты в .mdo‑файлах и XML‑описаниях. Эти файлы автогенерируемые, в них есть порядок элементов, который зависит от того, в каком порядке разработчик добавлял реквизиты и подсистемы. Два разработчика добавили по реквизиту в один справочник — получили конфликт.

Часть конфликтов EDT умеет разрешать автоматически через свой встроенный merge‑tool для XML — он понимает структуру файла и сливает изменения по смыслу. Запускается через стандартный механизм Eclipse: правый клик на конфликтном файле в Git Staging → Merge Tool.

Для случаев, которые автомерж не разрешил, открывается трёхпанельный редактор: ours, theirs, base. В нём конфликт правится вручную, потом файл помечается как разрешённый и коммитится.

Что делать НЕ нужно: лезть руками в XML конфликтного файла через Notepad++ или code, если плохо понимаете структуру метаданных. Один лишний пробел или перепутанный порядок узлов — и конфигурация перестаёт открываться в EDT, потом долго восстанавливаете из git reflog.

Некоторые проблемы

При первом переходе всплывают типичные проблемы.

1. Длина пути в Windows. Структура проекта EDT глубокая, и при длинных именах объектов на русском суммарная длина пути легко перешагивает лимит в 260 символов. Решение — git config --system core.longpaths true плюс размещение проекта в коротком пути вида C:edtcrm, а не в UsersИванов И. И.Documents1С РазработкаПроекты.

2. Скорость EDT на больших конфигурациях. Типовая ERP с импортом в EDT весит десятки гигабайт, и индексация на холодной машине занимает часы. Это разовая работа, но команду нужно к этому подготовить — первый день после переезда обычно «сидим, ждём индексации».

3. Кодировка консоли Windows. При работе с Git через командную строку имена файлов на русском часто отображаются как 320320324. Решение — git config --global core.quotepath false плюс выставить UTF-8 в реестре консоли Windows.

4. Хранилище и Git одновременно. На время переходного периода (две‑три недели) часто хочется работать и в Хранилище, и в Git параллельно. Это плохая идея — две системы перетирают изменения друг друга, и история становится непригодной для использования. Лучше выделить твёрдую дату перехода и после неё работать только через Git.

Итого

1С:EDT с Git — это серьёзный шаг вперёд относительно Хранилища: построчный diff, нормальный merge, code review через pull request, прозрачная история изменений, возможность подключать стандартные CI/CD‑инструменты. Цена — несколько дней на настройку, обучение команды и привычка коммитить чаще одного раза в день.

Главное при переходе — не пытаться сделать всё за один спринт. Сначала миграция одной средней конфигурации, отработка процесса на ней, потом постепенный перевод остальных проектов. Команде нужно две‑три недели, чтобы перестать делать «Сохранить изменения в хранилище» рефлекторно и привыкнуть к Git‑флоу.

Если после статьи хочется не просто прочитать про EDT и Git, а нормально встроить их в рабочий процесс 1С‑команды, присмотритесь к курсу «Профессиональная разработка в 1С:EDT + Git».

На курсе показываем, как работать с проектами в EDT, использовать Git в командной разработке, разбираться с ветками, конфликтами, расширениями и постепенно уходить от хаоса в изменениях к понятному процессу.

А начать можно с бесплатного открытого урока:

• 16 июня в 20:00. «Хаос в расширениях: знакомо? Выход — EDT». Записаться

^{На уроке поговорим о том, как навести порядок в расширениях, когда путаница в коде и метаданных уже мешает разработке. Преподаватель объяснит, почему расширения можно и нужно объединять в EDT, и покажет, как такой подход помогает сделать работу с 1С‑проектом более управляемой.}

Подписывайтесь на канал OTUS в MAX — там выходят анонсы открытых уроков, материалы по разработке и новости курсов.