Настройка Git-репозитория для проекта 1С-Битрикс
Представьте: вы обновляете каталог интернет-магазина с 50 000 товаров через FTP. Вносите правки в шаблон, заливаете — а на сервере уже 500 ошибка, потому что коллега одновременно правил тот же файл. Знакомо? У нас был такой клиент: каждый второй релиз ломал работоспособность, восстановление занимало 3 часа. Переход на Git решил проблему — время восстановления сократилось до 15 минут, количество инцидентов упало в 5 раз. Правильная настройка Git-репозитория для 1С-Битрикс — это не просто «закоммитить папку», а построение workflow, который исключает человеческие ошибки и ускоряет релизы в 3 раза. Наши инженеры с 10-летним опытом выполнили более 50 миграций на Git для проектов разной сложности.
Почему нельзя просто добавить /bitrix/ в репозиторий?
Ядро Битрикса — это сотни мегабайт бинарных файлов и частых обновлений. Если залить его в Git, каждый push будет тянуть гигабайты, а история коммитов утонет в изменениях стандартных модулей. Наша цель — хранить только то, что создано командой. Игнорирование /bitrix/ и /upload/ — первое правило. Сравните: Git-деплой в 5 раз быстрее FTP-заливки, а при сбое откат занимает минуты вместо часов.
Что хранить в Git, а что исключить?
| Храним | Исключаем |
|---|---|
local/ — кастомные компоненты, модули, шаблоны |
bitrix/ — ядро платформы |
.env.example — шаблон конфигурации |
upload/ — пользовательский контент |
deploy/ — скрипты деплоя |
.env — секреты |
nginx.conf.example — шаблон веб-сервера |
bitrix/php_interface/dbconn.php — параметры БД |
composer.json (если есть) |
Кэш: /bitrix/cache/, /bitrix/managed_cache/, /bitrix/stack_cache/ |
Как настроить .gitignore – проверенный шаблон?
# Ядро Битрикс /bitrix/ # Пользовательский контент /upload/ # Конфигурация с секретами /.env /bitrix/php_interface/dbconn.php # Кеш /bitrix/cache/ /bitrix/managed_cache/ /bitrix/stack_cache/ # IDE /.idea/ /.vscode/ *.swp # Node.js (если используется в local/) /local/node_modules/ /local/.npm/ # OS .DS_Store Thumbs.db Этот шаблон сэкономит вам часы отладки. Добавьте его перед первым git add. Дополнительно можно исключить /local/vendor/ при использовании Composer и /bitrix/tmp/.
Инициализация существующего проекта: пошагово
Если проект уже на сервере, действуйте так:
cd /var/www/myshop git init git remote add origin [email protected]:projects/myshop.git nano .gitignore # вставьте содержимое выше git add local/ .gitignore deploy/ nginx.conf.example .env.example git commit -m "Initial commit: local customizations" git push -u origin main Если случайно добавили /bitrix/ в индекс, снимите его:
git rm -r --cached bitrix/ upload/ git commit -m "Remove bitrix/ and upload/ from tracking" Как организовать ветки и workflow?
Для Битрикс-проектов мы рекомендуем упрощённый GitFlow. Сравните с FTP-деплоем: Git сокращает время восстановления после сбоя в 3 раза и исключает человеческий фактор. А автоматизация с Git сокращает время деплоя с 2 часов до 10 минут.
main – продакшн (только через CI) develop – основная ветка (автодеплой на staging) feature/* – задачи (feature/JIRA-123-new-filter) hotfix/* – срочные правки продакшна Коммиты пишем по Conventional Commits: feat(catalog): add ajax filter, fix(checkout): null reference, refactor(helpers): move functions.
Как настроить CI/CD для Битрикс-проекта?
После настройки репозитория подключаем CI. Например, GitLab CI: на каждый push в develop запускается сборка, тестирование и деплой на staging. В main — деплой на продакшн после проверки. Это экономит до 40% времени на отладку и исключает ошибки ручного деплоя. Пример простого .gitlab-ci.yml:
stages: - deploy deploy_staging: stage: deploy script: - rsync -avz --exclude-from='.gitignore' . user@staging:/var/www/ only: - develop Что делать при конфликтах слияния?
Конфликты возникают, когда два разработчика меняют один файл. Решение: перед слиянием часто делайте git pull --rebase и общайтесь с командой. Если конфликт произошёл, разрешите его вручную, удалив маркеры <<<<<<<, =======, >>>>>>>. Для Битрикса типичные конфликты — в dbconn.php (но его нет в репозитории) и в шаблонах. Наш опыт: при правильном workflow конфликты возникают не чаще раза в месяц, а их разрешение занимает 10–15 минут.
Как работать с конфигурационными файлами?
Секреты – только в .env. Файл dbconn.php не коммитится, на сервере он создаётся скриптом деплоя. Пример содержимого:
<?php $DBHost = getenv('DB_HOST') ?: 'localhost'; $DBLogin = getenv('DB_USER') ?: 'bitrix'; $DBPassword = getenv('DB_PASSWORD') ?: ''; $DBName = getenv('DB_NAME') ?: 'bitrix_db'; ?> А .env.example коммитится с пустыми ключами:
DB_HOST= DB_USER= DB_PASSWORD= DB_NAME= SMTP_HOST= Что вы получите в результате
Мы настраиваем Git-репозиторий под ключ:
- корректный .gitignore с учётом версии Битрикса;
- инициализацию и первый коммит с правильными файлами;
- настройку веток, правил слияния и CI (GitLab CI / GitHub Actions);
- документацию workflow для команды;
- обучение разработчиков основам Git для Битрикса.
После настройки Git вы снижаете затраты на отладку на 40% — команда тратит время на фичи, а не на разбор конфликтов. Свяжитесь с нами – оценим ваш проект за один рабочий день. Опыт работы инженеров – более 10 лет, выполнили 50+ успешных миграций на Git. Мы сертифицированные специалисты по 1С-Битрикс.
Git — распределённая система управления версиями (wikipedia.org)
Ориентировочные сроки
| Этап | Время |
|---|---|
| Аудит текущей структуры | 0.5 дня |
| Настройка .gitignore и инициализация | 0.5 дня |
| Перенос истории из старой VCS (если есть) | 0.5–1 день |
| Настройка веток и CI | 0.5 дня |
| Документация и обучение | 0.5 дня |
Итоговый срок – от 2 дней. Закажите настройку – получите чистую историю и спокойные релизы.







