Как настроить командную разработку в 1С:EDT и Git для конфигурации 1С

1С:EDT удобен для командной разработки тем, что конфигурация в нём представлена как проект из файлов, а не как единый непрозрачный объект. Это хорошо сочетается с Git: система контроля версий видит изменения в модулях, формах, шаблонах и служебных файлах проекта, а разработчики могут работать через ветки, коммиты, pull, merge и code review.

Для начинающего 1С-разработчика здесь важны две идеи. Первая: в EDT вы редактируете конфигурацию как обычный проект. Вторая: Git хранит историю изменений и помогает нескольким людям не перетирать работу друг друга. Но сама по себе кнопка Commit ещё не делает разработку командной: нужен понятный порядок подключения проекта, ежедневной синхронизации и разборов конфликтов.

Почему 1С:EDT подходит для работы в команде

Платформа поддерживает выгрузку конфигурации в набор файлов. Большинство конфигурационных данных попадает в XML-файлы, модули и текстовые документы — в текстовые файлы, изображения — в файлы соответствующих форматов, а материалы справки — в HTML. Благодаря этому изменения можно хранить в Git, сравнивать по версиям и возвращать при необходимости.

На практике это даёт несколько полезных эффектов:

• История становится читаемой. Видно, кто менял проект, какие файлы затронуты и в каком коммите это произошло.
• Изменения можно изолировать. Новую задачу удобно делать в отдельной ветке, не затрагивая основную линию разработки.
• Сравнение доступно на уровне проекта и объектов. В EDT можно сравнивать не только весь репозиторий, но и отдельные объекты, формы, команды, шаблоны и модули.
• Основные Git-операции встроены в среду. После подключения репозитория команды доступны через меню Team у проекта.

Это не отменяет аккуратности. Если два разработчика меняют один и тот же участок общего модуля или свойства одного объекта, конфликт всё равно возможен. Но EDT даёт для таких случаев встроенный сценарий сравнения и ручного слияния.

Как устроено файловое представление проекта

Когда конфигурация импортирована в EDT, вы работаете с ней как с проектом в рабочей папке. В интерфейсе это выглядит как дерево объектов и связанных с ними файлов, а для Git это обычное содержимое репозитория. Полезно понимать не внутреннюю служебную организацию каждой папки, а то, какие виды изменений реально попадают в систему контроля версий.

Из этого следуют два практических вывода. Во-первых, изменения в модулях особенно удобно отслеживать: Git хорошо показывает, какие строки добавлены или удалены. Во-вторых, для объектов конфигурации полезен именно compare/merge в EDT, потому что он показывает изменения в контексте проекта, а не только как сырой XML.

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

Как подключить проект к Git в 1С:EDT

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

Если репозиторий уже есть

1. Переключитесь в Git-представление и выполните Clone Git Repository.
2. Укажите адрес репозитория и данные доступа.
3. После клонирования откройте проект в EDT.
4. Проверьте, какая ветка активна: EDT показывает имя репозитория и текущей ветки рядом с названием проекта.

Если проект сначала вносится в Git

1. Импортируйте существующую конфигурацию в EDT.
2. Создайте удалённый Git-репозиторий.
3. Клонируйте его локально из EDT.
4. У проекта выберите Team > Share Project и укажите локальный репозиторий.
5. Сделайте первый коммит и отправьте его на сервер.

После этого основные действия выполняются через Team: переключение веток, pull, commit, push, merge и compare. Для первого коммита обычно открывается панель staging, где изменения нужно перенести из Unstaged Changes в Staged Changes, указать сообщение и выбрать Commit или Commit and Push.

Если конфигурация большая, при импорте иногда мешают слишком длинные пути ко временным XML-файлам. В таких случаях рабочее пространство и временную папку лучше располагать ближе к корню диска. В документации EDT также рекомендуется учитывать влияние антивирусной проверки на рабочие папки и локальные Git-репозитории: из-за постоянного сканирования среда может работать медленнее.

Повседневная работа с ветками и синхронизацией

Базовый порядок действий в EDT довольно простой.

1. Перед новой задачей переключитесь на основную ветку, обычно main или master.
2. Выполните Pull, чтобы получить последние изменения из удалённого репозитория.
3. Создайте отдельную ветку под задачу через Team > Create New Branch или Team > Switch To > New Branch.
4. Сделайте изменения в проекте.
5. Откройте Team > Commit, проверьте staging и зафиксируйте изменения.
6. Отправьте ветку на сервер через Push.

EDT позволяет называть ветки по шаблонам вроде feature/task1 или bugfix/239. Это не техническое требование среды, а удобный способ сделать назначение ветки понятным для всей команды.

При коммите стоит смотреть не только на сообщение, но и на состав файлов. Если в staging попали посторонние изменения, их лучше не смешивать с основной задачей. Для review и последующего merge намного удобнее, когда коммит соответствует одному понятному изменению.

После Push безопасный маршрут обычно такой: открыть pull request или merge request и пройти review перед вливанием в основную ветку. Это прямо поддерживает практику, описанную в учебных материалах по EDT: вместо прямых изменений в main команда использует запросы на слияние, чтобы изменения были просмотрены до объединения.

Что происходит при параллельных изменениях

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

Для 1С-проекта это типичная ситуация в общих модулях, модулях менеджера, формах и в свойствах одного и того же объекта. На сервере запрос на слияние может показать конфликт, а в EDT его уже приходится разбирать вручную.

Compare/Merge в EDT: как проходит сравнение и ручное слияние

Одна из сильных сторон EDT — возможность сравнивать и сливать изменения прямо в среде. Это полезно и для обычного merge веток, и для отката локальных незакоммиченных правок.

Сравнение с предыдущим состоянием

Если нужно отменить незакоммиченные изменения, EDT позволяет сделать это двумя способами:

• Compare and Merge — сначала сравнить текущее состояние с предыдущей версией, а потом осознанно выбрать, что переносить.
• Replace With — сразу заменить текущее состояние предыдущей версией.

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

При этом EDT умеет работать не только со всем проектом, но и с отдельными объектами. Ограничение важное: нельзя возвращать отдельный реквизит или табличную часть полностью независимо от родительского объекта — операции выполняются на уровне самого объекта.

Слияние другой ветки в свою

Когда в удалённой основной ветке появились изменения, а ваша задача ещё не завершена, в EDT можно подтянуть эти изменения к себе через Merge. Типовой сценарий выглядит так:

1. Переключиться на main и выполнить Pull.
2. Вернуться в свою рабочую ветку.
3. Открыть команду Merge в меню командной разработки и выбрать origin/main или локальную main, если она уже синхронизирована.
4. При необходимости открыть Compare/Merge editor.

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

После завершения merge EDT создаёт merge-коммит в текущей ветке. Затем этот результат нужно отправить в репозиторий. В учебном примере из документации после этого открывают push для текущего HEAD, просматривают изменения через Preview и только потом отправляют их на сервер.

Минимальный командный порядок, который реально работает

Если не усложнять процесс, для повседневной работы в EDT и Git достаточно такого минимума:

• перед новой задачей обновлять основную ветку через Pull;
• делать задачу в отдельной ветке;
• перед коммитом проверять staging, чтобы не утащить лишние файлы;
• отправлять изменения на review через pull request или merge request, а не вливать их в основную ветку напрямую;
• если сервер показывает конфликт, сначала подтянуть актуальную основную ветку к себе и разрешить конфликт в EDT, а уже потом повторно отправлять ветку.

Этого уже достаточно, чтобы работа была предсказуемой и прозрачной. Дальше команда может добавлять свои внутренние правила, но базовая связка EDT и Git полезна уже в таком виде: проект хранится в файлах, ветки изолируют задачи, compare/merge помогает понять различия, а review снижает риск случайных правок и спорных слияний.