Хранилище конфигурации — стандартный способ командной разработки в Конфигураторе 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.
Некоторые проблемы
При первом переходе всплывают типичные проблемы.
Длина пути в Windows. Структура проекта EDT глубокая, и при длинных именах объектов на русском суммарная длина пути легко перешагивает лимит в 260 символов. Решение —
git config --system core.longpaths trueплюс размещение проекта в коротком пути видаC:\edt\crm, а не вUsers\Иванов И. И.\Documents\1С Разработка\Проекты\.Скорость EDT на больших конфигурациях. Типовая ERP с импортом в EDT весит десятки гигабайт, и индексация на холодной машине занимает часы. Это разовая работа, но команду нужно к этому подготовить — первый день после переезда обычно «сидим, ждём индексации».
Кодировка консоли Windows. При работе с Git через командную строку имена файлов на русском часто отображаются как
\320\320\324. Решение —git config --global core.quotepath falseплюс выставить UTF-8 в реестре консоли Windows.Хранилище и 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 — там выходят анонсы открытых уроков, материалы по разработке и новости курсов.