Налаштування Git-репозиторію для проєктів на 1С-Бітрікс
Уявіть: ви оновлюєте каталог інтернет-магазину з 50 000 товарів через FTP. Вносите правки в шаблон, заливаєте — а на сервері вже 500 помилка, тому що колега одночасно правив той самий файл. Знайомо? У нас був такий клієнт: кожен другий реліз ламав працездатність, відновлення займало 3 години. Перехід на Git вирішив проблему — час відновлення скоротився до 15 хвилин, кількість інцидентів впала у 5 разів. Правильне налаштування Git-репозиторію для 1С-Бітрікс — це не просто «закомітити папку», а побудова workflow, який виключає людські помилки та прискорює релізи в 3 рази. Наші інженери з 10-річним досвідом виконали понад 50 міграцій на Git для проєктів різної складності. Наша компанія працює на ринку 5+ років, ми сертифіковані спеціалісти з 1С-Бітрікс, надаємо гарантію на всі налаштування.
Чому не можна просто додати /bitrix/ до репозиторію?
Ядро Бітрікса — це сотні мегабайт бінарних файлів і частих оновлень. Якщо залити його в Git, кожен push буде тягнути гігабайти, а історія комітів потоне в змінах стандартних модулів. Наша мета — зберігати лише те, що створено командою. Ігнорування /bitrix/ та /upload/ — перше правило. Порівняйте: Git-деплой у 5 разів швидший за FTP-заливку, а при збої відкат займає хвилини замість годин. Деплой через Git у 5 разів швидший за FTP, робота з Git у 3 рази ефективніша. Економія до $2000 на місяць за рахунок автоматизації рутинних операцій.
Що зберігати в 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:
git init - Додайте remote:
git remote add origin [email protected]:projects/myshop.git - Створіть файл .gitignore з наведеним вище вмістом:
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. Окрім того, ми впроваджуємо linter для PHP та code review, що підвищує якість коду. Автоматичне тестування вебхуками дозволяє виявляти помилки до деплою.
Як налаштувати 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
- Документацію workflow для команди
- Навчання розробників основам Git для Бітрікса
- Підтримку протягом місяця після налаштування
Наші переваги
Досвід роботи інженерів – понад 10 років. Компанія на ринку 5+ років. Виконано 50+ успішних міграцій на Git. Сертифіковані спеціалісти з 1С-Бітрікс. Гарантія на всі роботи – 12 місяців.
Орієнтовні терміни
| Етап | Час |
|---|---|
| Аудит поточної структури | 0.5 дня |
| Налаштування .gitignore та ініціалізація | 0.5 дня |
| Перенесення історії зі старої VCS (якщо є) | 0.5–1 день |
| Налаштування гілок та CI | 0.5 дня |
| Документація та навчання | 0.5 дня |
Підсумковий термін – від 2 днів. Замовте налаштування – отримайте чисту історію та спокійні релізи. Git — розподілена система керування версіями (wikipedia.org)