Как организовать работу с Git в 1С для типовых конфигураций и обойти ограничение GitHub на размер файлов?

← На главную

При попытке использовать Git для версионирования типовых конфигураций 1С (например, Бухгалтерии предприятия 3.0) разработчики неизбежно сталкиваются с проблемой: стандартная выгрузка конфигурации в файлы генерирует не только текстовые исходники модулей, но и тяжелые бинарные файлы. В частности, конфигурация поставщика сохраняется в виде единого файла .cf в папке ext\ParentConfigurations\. Поскольку размер современных типовых решений часто превышает 800 МБ, популярные облачные сервисы, такие как GitHub, блокируют загрузку (push), так как имеют жесткий лимит на размер одного файла в 100 МБ.

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

Анализ проблемы: почему стандартный подход не работает

Рассмотрим ситуацию: мы выполняем команду Конфигуратора "Выгрузить конфигурацию в файлы". 1С преобразует наши метаданные в дерево XML-файлов и текстовых файлов модулей. Однако для сохранения связи с поддержкой система создает в структуре выгрузки файл конфигурации поставщика. Проблема заключается в следующем:

Лимиты хранилищ: Бесплатные (и многие платные) аккаунты GitHub не принимают файлы более 100 МБ.
Избыточность данных: Передавать 800 МБ бинарных данных при каждом изменении кода — крайне неэффективно, особенно если конфигурация поставщика не менялась.
Специфика Git: Git оптимизирован для работы с текстом. Бинарные файлы превращают репозиторий в "раздутое" хранилище, которое быстро становится неповоротливым.

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

Решение 1: Использование Git LFS (Large File Storage)

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

Чтобы задействовать этот механизм, выполним следующие шаги в командной строке вашего локального репозитория:


# Инициализируем Git LFS в проекте
git lfs install

# Указываем Git LFS отслеживать все файлы .cf
git lfs track "*.cf"

# Добавляем файл настроек атрибутов в индекс
git add .gitattributes

После этого при выполнении git push файл конфигурации поставщика будет загружен в специальное хранилище, а в основном репозитории останется лишь ссылка на него. На другом компьютере при выполнении git pull расширение LFS автоматически скачает нужный бинарник.

Решение 2: Исключение конфигурации поставщика из Git

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

Создадим в корне проекта файл .gitignore и добавим туда маску для исключения конфигурации поставщика:


# Игнорируем бинарные файлы конфигураций поставщика
**/ParentConfigurations/*.cf
# Игнорируем прочие тяжелые бинарники
*.zip
*.rar

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

Развернуть на целевом компьютере пустую базу из того же шаблона поставщика (того же релиза).
Выполнить загрузку конфигурации из файлов через Конфигуратор или командную строку.

Важный момент: Если вы внесли изменения в саму конфигурацию поставщика (обновили релиз), вам придется передать этот файл один раз через любое облако (Google Drive, Яндекс.Диск) и положить в соответствующую папку перед загрузкой.

Решение 3: Поднятие собственного Git-сервера

Разберем ситуацию, когда безопасность или объемы данных не позволяют использовать публичные сервисы. Хорошей альтернативой GitHub являются Gitea или GitLab, развернутые на собственном сервере или локальной машине с белым IP.

Преимущества этого подхода:

Отсутствие лимитов: Вы сами устанавливаете максимальный размер загружаемого файла (в Gitea это правится одной строчкой в app.ini).
Скорость: В локальной сети передача сотен мегабайт будет мгновенной.
Конфиденциальность: Ваш код не покидает контур вашей инфраструктуры.

Решение 4: Автоматизация через Gitsync

Для профессиональной работы с Git в среде 1С рекомендуется использовать утилиту Gitsync. Она работает поверх OneScript и автоматизирует выгрузку/загрузку, попутно решая множество проблем Конфигуратора.

Проанализируем возможности Gitsync:

Нормализация файлов: Утилита сортирует объекты в XML так, чтобы при сравнении версий не возникало ложных различий из-за случайного порядка свойств, который выдает стандартный Конфигуратор.
Работа с поставщиком: Gitsync позволяет гибко настраивать, что именно должно попадать в репозиторий.
Автоматизация: Вы можете написать простой скрипт (bat или sh), который одной командой будет выгружать базу, коммитить изменения и пушить их в репозиторий.

Решение 5: Переход на 1C:EDT (Enterprise Development Tools)

Посмотрим на ситуацию с точки зрения современных инструментов разработки. 1C:EDT — это среда разработки на базе Eclipse, которая изначально спроектирована для работы с Git. В отличие от Конфигуратора, EDT по-другому управляет проектами поставщика.

В EDT конфигурация поставщика не хранится в виде огромного .cf внутри вашего рабочего проекта. Она подключается как внешняя зависимость. Это позволяет версионировать только ваш код, а связь с поддержкой обеспечивается средствами самой среды разработки. Однако стоит учитывать требования к аппаратному обеспечению: EDT потребляет значительно больше оперативной памяти, чем классический Конфигуратор.

Практические рекомендации по сборке конфигурации

Чтобы собрать полноценную рабочую конфигурацию из текстовых файлов на целевом сервере, используйте параметры командной строки. Это исключает ошибки человеческого фактора.

Пример команды для загрузки конфигурации:


1cv8.exe DESIGNER /F "ПутьКБазе" /LoadConfigFromFiles "ПутьКПапкеСИсходниками" /UpdateDBCfg

Если вы используете подход с разделением (код в Git, бинарник поставщика отдельно), убедитесь, что структура папок полностью соответствует той, что ожидает 1С. Путь ext\ParentConfigurations\ИмяКонфигурации.cf должен быть заполнен актуальным файлом до начала загрузки, если вы хотите сохранить статус "На поддержке".

Подводя итог, использование Git для 1С — это мощный инструмент, но он требует отказа от "ручного" копирования файлов в пользу настройки автоматизированных процессов и правильного управления тяжелыми бинарными данными.