Битрикс и Git: как вести разработку проектов без конфликтов

Интеграция Git с 1С-Битрикс — это стандарт современной веб-разработки, который разделяет программный код (версионируемые файлы) и контент (базу данных). Такой подход исключает конфликты при обновлении ядра, позволяет безопасно работать в команде и защищает боевой сервер от случайных ошибок, типичных для правки файлов напрямую через FTP.

Почему «по старинке» больше не работает

Давайте честно: все мы когда-то правили init.php прямо на боевом сервере в пятницу вечером через встроенный редактор админки или FileZilla. И у всех, абсолютно у всех, хоть раз после этого сайт ложился с белым экраном. 1С-Битрикс — система специфическая. Исторически она хранит половину логики в файлах, а половину — в базе данных. Это создает адский коктейль для системы контроля версий.

Если вы попытаетесь просто сделать git init в корне сайта и залить всё на GitHub, вы получите репозиторий на гигабайты, который невозможно обновлять. Ядро обновляется через админку, перезаписывает файлы, Git сходит с ума, возникают конфликты. Моя задача — показать вам архитектуру, которая выдерживает проверку временем и нервами разработчиков.

Архитектура папок: разделяй и властвуй

Первое правило бойцовского клуба Битрикс-разработчиков: не трогай папку /bitrix. Начиная с последних версий ядра (D7 и новее), вся кастомизация должна жить в специальной директории.

Переезд в /local

Если у вас шаблоны сайта всё еще лежат в /bitrix/templates/, вы живете в прошлом. Создавайте в корне папку /local. Это ваша песочница. Всё, что лежит здесь, Git должен отслеживать. Всё, что в /bitrix — это зона ответственности вендора (1С-Битрикс), и нам там делать нечего, кроме конфигов.

Настройка .gitignore — фундамент спокойствия

Самая частая ошибка — пушить лишнее. Кеш, логи, временные файлы восстановления. Если эти файлы попадут в репозиторий, при каждом мерже вы будете разгребать конфликты. Ниже — проверенный годами конфиг, который отсекает весь мусор.

/bitrix/*
!/bitrix/templates/  # Оставляем только если у вас легаси и нет папки local
!/bitrix/components/ # Аналогично для старых проектов
/upload/
/bitrix/cache/
/bitrix/managed_cache/
/bitrix/html_cache/
*.restore.php
/local/php_interface/dbconn.php # Пароли от БД — только на сервере!
/bitrix/.settings.php           # Основные настройки соединения
/bitrix/.settings_extra.php     # Локальные оверрайды (об этом ниже)
*.log
/public_html/sitemap*.xml

Решение проблемы конфигураций

Классическая ситуация: разработчик Вася включил у себя debug => true, чтобы видеть ошибки. Закоммитил файл .settings.php. Этот файл улетел на прод. Теперь все посетители интернет-магазина видят стек трейс ошибки вместо красивой 404 страницы. Бизнес теряет деньги.

Лайфхак с .settings_extra.php

Битрикс умеет подключать дополнительный файл настроек, если он существует. Это спасение для командной разработки.

1. Основной .settings.php (с доступами к боевой БД) лежит на сервере и никогда не попадает в Git.
2. В .gitignore добавляем /bitrix/.settings_extra.php.
3. Каждый разработчик создает этот файл у себя локально и переопределяет там нужные ключи: подключение к своей локальной базе, режим отладки, вывод ошибок.

В итоге, даже если вы пушите изменения, настройки окружения не перезатираются. Это принцип Immutable Infrastructure в миниатюре.

База данных: Главная боль и её лечение

Git версионирует строки кода. Он понятия не имеет, что вы зашли в админку, кликнули "Создать инфоблок", добавили свойство "Артикул" и сохранили. Это изменение записалось в MySQL, а не в файл. Если вы запушите код компонента, который использует это свойство, на сервер, сайт упадет, потому что на сервере этого свойства в базе еще нет.

Решение: Миграции БД.

В 2025 году создавать структуру базы данных руками на проде — дурной тон. Мы используем подход "Migration as Code".

Как это работает на практике:

• Инструмент: Стандарт де-факто — модуль arrilot/bitrix-migrations. Он бесплатный и надежный.
• Процесс: Вы создаете свойство инфоблока на локальной машине. Запускаете команду, которая генерирует PHP-файл миграции. В этом файле описано: "Создать свойство X в инфоблоке Y".
• Деплой: Этот файл летит в Git. На сервере при деплое автоматически запускается скрипт, который "накатывает" миграцию. База данных на проде обновляется синхронно с кодом.

CI/CD Pipeline: Автоматизация рутины

Копирование файлов руками — это риск человеческого фактора. Я, например, могу забыть залить один файл CSS, и верстка поедет. Робот не забывает. Настройте простой пайплайн (GitLab CI, GitHub Actions или Jenkins), который делает всё за вас.

Вот как выглядит здоровый процесс доставки кода:

1. Build: Сборка фронтенда (npm run build). Не храните скомпилированные bundle.js и style.css в репозитории — собирайте их на лету.
2. Atomic Deploy: Код заливается в новую папку на сервере. Создается симлинк. Это позволяет переключить сайт на новую версию мгновенно, без простоя.
3. Migration: Запуск php migrator migrate. Структура БД обновляется.
4. Clear Cache: Обязательный сброс тегированного и managed кеша. Иначе Битрикс будет отдавать старые данные с новой версией кода.

Коммерческие аспекты и инструменты

Часто спрашивают: сколько стоит внедрить такой процесс? Сама технология Git бесплатна. Но инструменты вокруг могут требовать бюджета, хотя для старта почти всегда есть Free-тарифы.

Внедрение этих практик — это инвестиция. По метрикам Яндекса (Proxima), сайты с высокой технической стабильностью и скоростью ранжируются лучше. А отсутствие простоев из-за кривого деплоя напрямую влияет на поведенческие факторы.

Когда стоит делегировать техническую часть

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

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

Частые вопросы