Git и .gitignore для проекта на 1С-Битрикс: один сайт и пара окружений

Зачем версионировать код Битрикс-проекта

Система контроля версий снимает типичную боль веб-команды: параллельные правки больше не затирают друг друга благодаря веткам и ревью, раскладка изменений по десяткам файлов уходит через git pull вместо ручной «накатки». История помогает ответить, кто и когда ввёл регрессию; при подозрении можно пройти git bisect, а нужное состояние года назад — это обычный переход по коммиту, а не поиск архива по почте.

Удалённый репозиторий — это не «удалённый» в бытовом смысле: это копия на сервисе вроде GitHub или GitLab, с которой синхронизируются локальные машины через git push и git fetch.

Что обычно хранится в Git, а что нет

У многих публичных страниц есть физический файл под корнем — их разумно отслеживать целиком. Кастом чаще лежит в /local/; эту директорию обычно можно добавлять почти без оговорок. С /bitrix/ сложнее: ядро и стандартные модули тянутся обновлениями маркетплейса, а вместе с ними там бывают артефакты, которые не должны утекать из контура окружения. Минимум, что обязательно убрать из индекса: подключение к базе (/bitrix/php_interface/dbconn.php, /bitrix/.settings.php) и производные каталоги кеша.

В корне часто лежит .htaccess и robots.txt с привязкой к домену — для стендов удобнее держать отдельные варианты и не смешивать их с боевым снимком в общей истории. Аналогично не добавляют выгрузки SQL, дампы из крон-задач, карты sitemap*.xml, служебные файлы IDE и временные заготовки вида ~*.

Стартовый .gitignore: скелет под Bitrix

Ниже — укрупнённая заготовка: перечень легко дополнить под ваш тариф хостинга и структуру сайта; цель блока — зафиксировать принципы (ядро скрыть, загрузку и кеш не тащить, секреты не коммитить).

# IDE и хвосты ОС
.idea/
*.log
*.sql
/*.html
/upload/
/logs/
/robots.txt
/.htaccess
/sitemap*.xml
.DS_Store
Thumbs.db

# Секреты и тяжёлые деревья ядра
/bitrix/.settings.php
/bitrix/php_interface/dbconn.php
/bitrix/php_interface/include/sale_payment/
/bitrix/php_interface/include/sale_delivery/
/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/bitrix/html_pages/
/bitrix/resize_cache/
/bitrix/modules/
/bitrix/components/
/bitrix/js/
/bitrix/css/
/bitrix/images/
/bitrix/admin/
/bitrix/backup/
/bitrix/themes/
/bitrix/wizards/

В проектах без жёсткого запрета можно опереться на готовые community-списки и удалить строки, если у вас, наоборот, нужно версионировать нестандартный кусок /bitrix/ — главное сохранять правило: репозиторий не становится складом дампов и кеша.

Один сайт: первичная инициализация

Когда в проектной ферме только один кодовый корень, схема самая простая: подготовить .gitignore, выполнить git init, проиндексировать файлы под правила игнора и сделать первый коммит. Имя и почта пользователя должны совпасть с учёткой на удалённом сервисе, чтобы авторство в журналах выглядело последовательно.

cd /path/to/site
curl -fsSL -o .gitignore \
  "https://raw.githubusercontent.com/MashinaMashina/Bitrix/master/gitignore"
git init
git add -A
git config user.name "Your Name"
git config user.email "your@example.com"
git commit -m "Initial import"

Дальше связываем локальный корень с пустым проектом на хостинге и отправляем ветку. Типичные команды после создания репозитория в веб-интерфейсе:

git remote add origin https://github.com/your-namespace/your-repo.git

git push -u origin main (если платформа уже создала ветку main; у старых инструкций встречалось имя master — используйте фактическое имя удалённой ветки).

Два стенда: как соединить несвязанные истории

Отдельные git init на продакшене и тестовом сервере дают два дерева без общего предка, и обычный merge отказывается с сообщением вида «refusing to merge unrelated histories». Рабочий приём — заранее выбрать эталон (условный прод), вытянуть его историю на стенд и один раз аккуратно склеить ветку стенда, разрешая конфликты в сторону боевых файлов, после чего пуш уже содержит единое дерево для обоих окружений.

• На боевой копии инициализируйте Git по сценарию выше и выполните git push.
• На тестовой копии тоже сделайте локальный первый коммит, добавьте тот же origin, но не публикуйте свою главную ветку, пока не выполните шаги ниже.

На тестовой машине:

git fetch origin
git checkout origin/main
# если у вас на удалённом репозитории ветка называлась master, подставьте origin/master
git checkout -b merge-bridge
# В merge-bridge сейчас файлы как на проде: сливаем «наш» тестовый main/master
git merge main --strategy=ours --allow-unrelated-histories
# или: git merge master ... — по фактическому имени локальной ветки стенда
git checkout main
git merge merge-bridge
git push origin main

Смысл ключевых шагов

git fetch подтягивает коммиты с удалённой стороны без автоматического слияния в рабочую копию. Переключение на origin/main выравнивает файлы эталону, временная ветка merge-bridge сохраняет это состояние как опорную точку. Опции --strategy=ours вместе с --allow-unrelated-histories сообщают Git, что спор между двумя несовместимыми корнями разрешается в пользу текущего снимка — то есть содержимое остаётся «как на проде», но в граф попадают обе истории.

Обратное переключение на главную ветку стенда и обычный git merge merge-bridge уже не ломает рабочие файлы конфликтами: связующий коммит существует, остаётся отправить результат на удалённый сервис. На прод после этой операции файл на диске не меняется, пока сознательно не заберёте обновление — главное держать в голове, что эталоном при первом столкновении вы выбрали боевой контур.

Краткий итог

Репозиторий под Bitrix начинают с аккуратного .gitignore, который режет секреты, кеш и бинарные артефакты. Удалённый Git избавляет от ручного перекладывания правок и даёт понятную историю. Когда нужно синхронизировать два уже живущих локальных repo без общего предка, разовое слияние с --allow-unrelated-histories и стратегией ours на стороне прода экономит недели попыток «склеить два zip-архива вручную».