Git и Битрикс: что версионировать, а что нет

Ядро Битрикса и его особенности файловой структуры плохо сочетаются с наивным "положить весь проект в Git" — часть каталогов должна версионироваться, часть категорически нет. Разберём, что реально стоит включать в репозиторий проекта на 1С-Битрикс, а что исключить.

Что не версионировать: ядро системы

Каталог bitrix/modules/ с ядром системы и штатными модулями не стоит версионировать в проектном репозитории — он обновляется собственным механизмом обновлений системы, независимым от Git, и включение его в репозиторий раздувает историю коммитов без практической пользы, создавая огромные диффы при каждом системном обновлении.

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

# .gitignore
/bitrix/modules/
/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/bitrix/html_pages/
/bitrix/backup/
/upload/
/bitrix/php_interface/dbconn.php
.settings.php

Каталоги кеша, резервных копий и загруженных файлов исключаются по тем же соображениям — это данные, генерируемые при работе сайта, а не исходный код проекта, версионирование которого имеет смысл. Файл dbconn.php с реквизитами подключения к базе исключается отдельно по соображениям безопасности — секреты не должны попадать в историю Git даже в приватном репозитории.

Что версионировать: проектная часть

• Локальные модули в /local/modules/.
• Кастомные шаблоны компонентов и сайта в /local/templates/ или переопределённые внутри bitrix/templates/, если структура проекта построена так.
• Файл init.php и остальное содержимое /local/php_interface/.
• Собственные компоненты, обработчики событий, вся написанная прикладная логика проекта.

Управление секретами через переменные окружения или отдельный файл

<?php
// dbconn.php, версия для .gitignore
$DBHost = getenv('DB_HOST') ?: 'localhost';
$DBLogin = getenv('DB_LOGIN') ?: '';
$DBPassword = getenv('DB_PASSWORD') ?: '';
$DBName = getenv('DB_NAME') ?: '';

Вместо хранения реквизитов подключения прямо в исключённом из репозитория файле, что требует ручной настройки на каждом новом окружении, удобнее читать значения из переменных окружения — тогда сам код файла подключения может версионироваться (без реальных секретов внутри), а секреты настраиваются отдельно на каждом сервере через переменные окружения или защищённое хранилище секретов CI/CD.

Ветвление и деплой без прямого доступа к продовым файлам

Для команд с несколькими разработчиками осмысленно организовать ветвление (feature-ветки, ветка для стейджинга, ветка для прода) и настроить автоматический деплой через CI/CD вместо ручного копирования файлов на сервер по FTP — это снижает риск случайного переноса незавершённых изменений на боевой сайт и даёт понятную историю того, что и когда было выложено.

Проблема бинарных файлов в истории репозитория

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

Частые ошибки

• Каталог bitrix/modules/ включён в репозиторий целиком. Огромные диффы при каждом системном обновлении без практической пользы.
• Файл с реквизитами подключения к базе закоммичен в историю. Риск утечки секретов даже из приватного репозитория.
• Деплой выполняется вручную по FTP в обход истории Git. Теряется понятная история изменений, попавших на боевой сервер.

Итог

Репозиторий проекта на 1С-Битрикс должен содержать только проектную часть — локальные модули, шаблоны, init.php и прикладную логику — исключая ядро системы, кеш и загруженные файлы через .gitignore. Реквизиты подключения к базе и другие секреты правильнее вынести в переменные окружения, а не хранить ни в версионируемом, ни даже в исключённом из версионирования файле без дополнительной защиты.