Командная разработка в 1С:EDT с Git: как организовать базовый рабочий процесс
Два разработчика изменили одну конфигурацию, обменялись файлами и обнаружили, что часть доработок исчезла. Git помогает хранить историю и сопоставлять изменения, но не решает за команду, какой результат правильный. В 1С:EDT контроль версий встроен в рабочий процесс: можно создавать ветки, просматривать состав commit и разбирать слияние через средства сравнения.
Разберём авторский регламент для небольшой команды: основная ветка main, отдельная ветка на задачу, проверка коллегой и тестовая информационная база у каждого разработчика. Это выбранные договорённости, а не обязательные названия и правила продукта.
Подготовьте среду и изолируйте проверочную базу
Для начала установите согласованную в команде версию EDT и совместимую платформу 1С:Предприятие. Официальное руководство описывает установку через 1C:EDT Start и отдельный offline-пакет. Версии и системные требования сверяйте для выбранного выпуска: один список из старого примера не подходит всем конфигурациям.
Подготовьте доступ к Git-хостингу и способ аутентификации. Учётные данные нужны для подключения, но не для хранения в проекте. Отдельно определите локальную тестовую информационную базу. Проект с исходниками и база, в которой запускается приложение, выполняют разные роли; успешный commit не означает обновление конфигурации рабочей базы.
В настройках запуска EDT указываются проект, используемая информационная база и клиентское приложение. Перед первым запуском проверьте их явно. Не используйте пользовательскую рабочую базу как случайную среду для учебного опыта с ветками и конфликтами.
Новый проект и уже существующий репозиторий
Если команда уже работает в Git, клонируйте её репозиторий и подключите проект по принятой инструкции. Не импортируйте параллельно другую копию конфигурации и не объявляйте её той же исходной версией без сверки. Первое полезное наблюдение — какая ветка открыта и какой commit считается исходным.
Для конфигурации, которая пока существует только в информационной базе, руководство 1С описывает сначала импорт в EDT, затем подключение проекта к Git. На Git-хостинге создают репозиторий, в Git Perspective выбирают Clone Git Repository и получают локальную копию. После этого в 1C:Enterprise Perspective для импортированного проекта используют Team → Share Project и выбирают локальный репозиторий.
Это маршрут первичного подключения, а не действие на каждый рабочий день. После него в заголовке проекта видна связь с репозиторием. Перед начальным commit просмотрите фактический состав файлов и убедитесь, что импортирована нужная конфигурация.
Что включать в историю
История должна позволять другому разработчику получить согласованный исходный EDT-проект: метаданные конфигурации, тексты модулей и другие необходимые проекту файлы. Не путайте этот набор с резервной копией информационной базы. Данные пользователей, локальные журналы и секреты подключения не становятся исходным кодом только потому, что лежат рядом.
| Группа | Авторское правило команды |
|---|---|
| Исходники и необходимые общие настройки проекта | Включаем после просмотра; проверяем воспроизводимость на другой машине |
| Документация и сценарии проверки | Храним вместе с изменением, если они нужны для его понимания |
| Личные настройки среды и временные результаты | Отделяем от общих файлов, правила исключения согласуем заранее |
| Рабочие базы, реальные данные, пароли и токены | Не включаем в репозиторий; для тестирования используем подготовленную среду |
Не копируйте универсальный .gitignore без проверки. Слишком широкое исключение способно спрятать нужный файл, а отсутствие исключений — добавить посторонние данные. Перед отправкой смотрите Git Staging, а не полагайтесь на кнопку добавления всего содержимого.
Проект, дерево объектов и база: что видит разработчик
В Navigator EDT на верхнем уровне находятся проекты. Проект конфигурации содержит одну конфигурацию с деревом объектов; расширение — отдельный проект своего типа. Формы и модули редактируются в соответствующих редакторах. Рабочая информационная база отображается и используется отдельно: это место запуска и проверки приложения, а не то же самое, что исходный проект.
Для нашей задачи логическая схема выглядит так: «Проект конфигурации → Документы → Заказ → реквизиты, формы и модуль объекта». Это учебное представление дерева Navigator, а не буквальные имена каталогов на диске. Если добавлен реквизит и изменён модуль, в Git Staging нужно проверить обе части доработки. Один текст модуля не описывает новое поле метаданных.
После commit коллега должен получить изменённое описание объекта и связанный код, а затем проверить обновление своей тестовой базы и сценарий ввода заказа. Записи реальных заказов и пользователей этим commit не передаются. Конфигурацию проекта и конфигурацию базы синхронизируют предусмотренным EDT процессом; эту операцию проверяют отдельно от отправки исходников на Git-хостинг.
Одна задача: от актуальной main до push
- Убедитесь, что незавершённые локальные изменения сохранены понятным способом и не потеряются при переключении.
- Переключитесь на main и выполните Pull. В примерах руководства основная ветка также может называться master — используйте название своего репозитория.
- Создайте отдельную ветку через Team → Create New Branch либо Team → Switch To → New Branch. В нашем регламенте пример имени — feature/142-order-check.
- Внесите изменение и проверьте его в своём EDT-проекте и тестовой базе.
- Откройте Team → Commit, просмотрите Unstaged Changes и перенесите только нужные файлы в Staged Changes.
- Запишите содержательное сообщение и выполните Commit либо Commit and Push. В первом случае запись остаётся локальной до отдельной отправки.
Сообщение «Добавлена проверка обязательного реквизита заказа» полезнее, чем «правки». Commit должен описывать связанное изменение. Не присоединяйте к исправлению проверки случайное переименование десятков объектов, если оно не требуется задаче: коллегам будет труднее увидеть смысл и разобрать возможный конфликт.
После push откройте merge request или pull request по правилам хостинга. Укажите задачу, поведение до и после, затронутые объекты и выполненные проверки. В нашем процессе основная ветка принимает изменения после просмотра коллегой; технические ограничения прямого push настраиваются на стороне хостинга.
Конфликт: объединяем смысл, а не выбираем сторону целиком
Условный пример: первый разработчик добавил проверку заполнения реквизита в общий модуль, второй изменил рядом формирование сообщения пользователю. Вторая задача уже вошла в main. При попытке объединить первую ветку Git не смог автоматически согласовать тот же участок текста.
Сначала сохраните собственную работу. Затем обновите main через Pull, вернитесь в ветку задачи и выполните слияние актуальной основной ветки в свою. Руководство 1С показывает выбор Merge в инструментах командной разработки и открытие Compare/Merge Editor. Названия элементов могут зависеть от используемой версии и контекста меню.
В редакторе сравните текущую сторону, присоединяемую и итоговый результат. В нашем примере итог должен сохранить и проверку реквизита, и правильное новое сообщение. Выбор «взять другую сторону» целиком без просмотра способен удалить одну из независимых доработок. Это особенно заметно, когда объект содержит больше изменений, чем показанная конфликтная строка.
После подтверждения слияния проверьте проект и поведение на тестовых данных, затем отправьте результат в ветку задачи и обновите merge request. Исчезновение текстового конфликта не доказывает отсутствие логического: обе строки могут сохраниться, но выполняться в неправильном порядке.
Откат и подмена — не синонимы безопасного слияния
EDT предоставляет Compare With и Replace With для сравнения и замены версией из истории. Replace With способен заменить выбранный объект или проект без поэлементного выбора, поэтому перед ним нужно понять, какие несохранённые изменения будут потеряны. Для разбора отличий сначала используйте сравнение.
В руководстве отдельно оговорено, что реквизит или табличную часть нельзя откатить изолированно тем же способом: выбирают родительский объект. Учитывайте границы операции, а не только то место, на котором стоял курсор. История Git полезна именно возможностью восстановить обоснованную версию, а не поводом применять замену наугад.
Минимальные договорённости команды
Зафиксируйте основную ветку, правила именования задач, состав репозитория, порядок обновления и review, ответственность за конфликт и набор проверок перед merge. Отдельно опишите выпуск и обновление баз: они не должны подразумеваться одним словом «залили».
Практическая приёмка процесса проста: второй разработчик получает проект из репозитория, понимает историю изменения и может воспроизвести проверку в подготовленной базе. Если для этого требуется искать последнюю копию модуля в переписке, часть командного процесса ещё остаётся вне Git.
