Разработка и Конфигурация · 10 мин
Что такое Git для 1С и зачем он нужен разработчику
Git для 1С: что это, зачем нужен контроль версий конфигурации, как работать через EDT, сравнение с хранилищем конфигурации, типичные ошибки и FAQ.
Git для 1С — это применение распределённой системы контроля версий Git к исходному коду конфигураций 1С:Предприятие. Вместо классического хранилища конфигурации разработчики сохраняют историю изменений в Git-репозитории: каждый коммит фиксирует, кто, когда и что изменил в коде модулей, форм и метаданных. Такой подход стал стандартом в командах, работающих через 1C:Enterprise Development Tools (EDT), поскольку EDT изначально хранит конфигурацию в виде текстовых файлов, удобных для версионирования.
Ключевое отличие от привычного хранилища конфигурации — распределённость и ветвление. Каждый разработчик имеет полную копию репозитория на своём компьютере, может создавать отдельные ветки под задачи, экспериментировать без риска сломать основную версию и сливать изменения через merge-запросы. Это принципиально меняет организацию командной разработки: пропадает необходимость «захватывать» объекты, появляется возможность код-ревью и параллельной работы над разными функциями.
Важно понимать: Git не заменяет платформу 1С и не работает напрямую с базой данных. Он версионирует исходный код конфигурации — файлы проекта EDT или выгрузку конфигурации в XML. Для обновления рабочей информационной базы по-прежнему используется загрузка конфигурации штатными средствами платформы.
Что именно версионируется и как это устроено
В классическом конфигураторе 1С конфигурация хранится внутри информационной базы в бинарном виде, поэтому «просто положить базу в Git» нельзя — смысла в этом нет. Чтобы Git стал полезным, конфигурацию нужно представить в виде набора текстовых файлов. Существует два основных способа: проект 1C:EDT, где исходники изначально хранятся как файлы на диске, и иерархическая выгрузка конфигурации в XML-файлы из конфигуратора.
В репозиторий попадают модули объектов и общих модулей, описания метаданных, формы, макеты, права и прочие элементы конфигурации. Не версионируются данные информационной базы: справочники, документы, регистры — это содержимое базы, а не исходный код. Также обычно исключают из репозитория служебные файлы проекта, временные каталоги и файлы настроек, специфичные для конкретного компьютера.
Чем Git отличается от хранилища конфигурации 1С
Хранилище конфигурации — встроенный механизм платформы для совместной разработки: объекты захватываются одним разработчиком, остальные в это время не могут их менять. Это просто и надёжно для небольших команд, но создаёт очереди при активной работе над одними и теми же объектами и не поддерживает параллельные ветки разработки.
Git работает иначе: каждый разработчик изменяет свою копию, а расхождения разрешаются при слиянии веток. Это даёт гибкость, но требует понимания конфликтов слияния. Если два разработчика изменили один и тот же модуль, при слиянии потребуется вручную объединить изменения — автоматика не всегда справляется.
| Критерий | Хранилище конфигурации | Git + EDT |
|---|---|---|
| Модель работы | Захват объектов, последовательные правки | Ветки и параллельная разработка |
| История изменений | По версиям хранилища | Полная история коммитов с авторами |
| Код-ревью | Не предусмотрено штатно | Через merge request на Git-сервере |
| Работа офлайн | Нужно подключение к хранилищу | Локальные коммиты без сети |
| Порог входа | Низкий, привычен разработчикам 1С | Требует освоения Git и EDT |
Сравнение вариантов
Подходит небольшим командам до 3–5 разработчиков, работающим в конфигураторе. Ограничение: нет веток и ревью, блокировки при захвате объектов.
Подходит командам с параллельной разработкой, несколькими релизными линиями и практикой код-ревью. Ограничение: требует перехода на EDT и обучения Git.
Компромисс для тех, кто остаётся в конфигураторе, но хочет историю в Git. Ограничение: слияние XML-файлов сложнее, выгрузку нужно автоматизировать.
Как начать работать с Git в 1C:EDT
1C:EDT построена на платформе Eclipse и содержит встроенную поддержку Git. Типовой сценарий выглядит так: создаётся новый проект или импортируется существующая конфигурация из информационной базы, затем проект помещается под контроль Git через контекстное меню «Team → Share Project». После этого проект можно подключить к удалённому репозиторию на Git-сервере — GitLab, GitHub, Bitbucket или корпоративном аналоге.
Ежедневный цикл работы разработчика: получить свежие изменения из основной ветки (pull), создать ветку под задачу, внести изменения в код, зафиксировать их коммитом с понятным сообщением, отправить ветку на сервер (push) и открыть запрос на слияние. После ревью изменения попадают в основную ветку.
- 1Установите 1C:EDT и создайте новый проект или импортируйте конфигурацию из информационной базы
- 2Откройте контекстное меню проекта: Team → Share Project, выберите Git и создайте локальный репозиторий
- 3Добавьте файл .gitignore для служебных каталогов, чтобы мусор не попадал в историю
- 4Выполните первый коммит с базовым состоянием конфигурации
- 5Настройте подключение к удалённому репозиторию и выполните push
- 6Проверьте на Git-сервере, что файлы проекта видны и история коммитов отображается
Как проверить, что всё настроено правильно
После подключения репозитория стоит убедиться, что версионируется именно исходный код, а не служебные файлы. Откройте репозиторий на Git-сервере: там должны быть каталоги проекта с модулями и метаданными, но не должно быть локальных настроек рабочего пространства и временных файлов. Если в истории появляются файлы, меняющиеся сами по себе при каждом запуске EDT, их нужно внести в .gitignore.
Вторая проверка — воспроизводимость. Клонируйте репозиторий в отдельный каталог, импортируйте проект в чистое рабочее пространство EDT и убедитесь, что конфигурация собирается без ошибок и её можно загрузить в тестовую информационную базу. Если проект открывается только на компьютере автора — в репозиторий не попала часть необходимых файлов.
Как проверить результат
Только исходники проекта и .gitignore
Локальные настройки, временные и бинарные файлы
Проект импортируется и конфигурация обновляет тестовую базу
Ошибки импорта или отсутствующие файлы
Понятные сообщения, указан автор, атомарные изменения
Коммиты «fix», «правки» без описания сути
Типичные ошибки и риски при работе с Git в 1С
Самая частая ошибка — попытка версионировать файл базы данных или файловую выгрузку .dt. Git плохо работает с большими бинарными файлами: репозиторий быстро разрастается, а сравнить версии бинарника невозможно. Версионируется только исходный код конфигурации.
Вторая группа проблем связана со слиянием. Разработчики, привыкшие к хранилищу конфигурации, иногда разрешают конфликты «в свою пользу», затирая чужие изменения. Перед завершением слияния нужно сравнить результат с обеими ветками и обязательно проверить конфигурацию на тестовой базе. Ещё одна ошибка — редактирование одной конфигурации параллельно в конфигураторе и в EDT: форматы хранения различаются, и изменения легко потерять.
Ограничения и альтернативы
Git не решает все задачи командной разработки в 1С. Он не версионирует данные, не управляет релизами сам по себе и не заменяет тестирование. Для полноценного цикла поставки Git обычно дополняют автоматической сборкой и проверками — например, запуском синтаксического контроля и автотестов при каждом слиянии в основную ветку.
Если команда маленькая и работает в конфигураторе, переход на Git может не окупиться: хранилище конфигурации покрывает базовые потребности с меньшими затратами на обучение. Git оправдан, когда есть параллельные задачи, несколько поддерживаемых версий продукта, требования к код-ревью или интеграция с внешними инструментами разработки.
Как выбрать действие
Частые вопросы о Git в 1С
Можно ли использовать Git с обычным конфигуратором без EDT?
Да, через выгрузку конфигурации в файлы XML (иерархический формат) с последующим коммитом в Git. Выгрузку обычно автоматизируют пакетным запуском конфигуратора. Минус подхода: слияние XML-файлов при конфликтах заметно сложнее, чем работа с проектом EDT, и требуется дисциплина регулярной выгрузки.
Нужен ли отдельный Git-сервер или достаточно локального репозитория?
Локальный репозиторий подходит для личной истории одного разработчика. Для команды нужен общий сервер: GitLab, GitHub, Bitbucket или самостоятельно развёрнутый экземпляр. Сервер даёт центральную точку обмена, merge-запросы для ревью и резервную копию истории.
Что делать, если при слиянии возник конфликт в модуле?
Git помечает конфликтные участки в файле. Откройте файл, сравните обе версии изменений и вручную оставьте корректный вариант, объединив логику обеих правок при необходимости. После разрешения конфликта зафиксируйте результат коммитом и обязательно проверьте работоспособность конфигурации на тестовой базе.
Хранит ли Git данные информационной базы?
Нет. Git версионирует только исходный код конфигурации — модули, метаданные, формы. Данные базы (документы, справочники, регистры) защищаются штатными средствами резервного копирования СУБД или выгрузкой .dt, и это отдельный процесс.
Как перенести историю из хранилища конфигурации в Git?
Прямой полноценный перенос истории затруднён из-за разных моделей хранения. На практике чаще всего фиксируют текущее состояние конфигурации первым коммитом и ведут историю дальше уже в Git. Если критична старая история, хранилище конфигурации сохраняют в архивном режиме «только чтение».
Можно ли работать с Git в 1С без командной строки?
Да. В 1C:EDT основные операции — коммит, pull, push, создание веток и слияние — доступны через графический интерфейс в перспективе Git. Командная строка понадобится для редких операций вроде интерактивного перебазирования или сложного восстановления истории.
Что важно запомнить
Git для 1С — это контроль версий исходного кода конфигурации, чаще всего через 1C:EDT. Он даёт ветвление, историю и код-ревью, но требует дисциплины при слиянии и не заменяет резервное копирование баз. Переход оправдан для команд с параллельной разработкой; небольшим командам часто достаточно хранилища конфигурации.