Практики Git на проекте 1С‑Битрикс: стенд, ветки и выкладка без FTP

Зачем команде нужен Git на Битрикс‑проекте

Версионирование фиксирует снимки файлов проекта: видно, что менялось, кем и в каком порядке. Несколько человек могут вести параллельные линии работы, а перенос между серверами сводится к осмысленным коммитам и git pull, а не к ручному списку из сотни путей.

Ситуация без Git на длинной доработке: на тестовом всё собрано месяцами, на прод нужно отдать тот же результат. Вручную легко забыть один файл из девяноста девяти или затереть чужую правку, если на боевом уже успели что‑то поменять. Нужен предсказуемый способ доставлять изменения целиком и проверяемо.

Почему текст из панели администратора не попадает в историю Git

Сценарий «где в Git правки контента?» возникает из смешения двух слоёв. Программная логика сайта лежит в файлах на диске: подключается множество модулей и шаблонов при одном запросе, и этот набор сравнительно компактен и редко меняется «на лету» средствами веб‑интерфейса.

Материалы страниц, каталоги новостей и другой наполняемый через админку массив живёт в базе данных. Там удобно искать одну запись среди миллионов по фильтрам и безопасно допускать одновременное редактирование разными редакторами; размер контента и частота правок делают базу естественным местом хранения. Git отслеживает файловое дерево репозитория, а не строки в таблицах СУБД, поэтому типичные текстовые правки из админки в коммитах не видны — это нормальное разделение ответственности между кодом и контентом.

Как устроены pull и push

git push отправляет ваши коммиты на удалённый сервис (GitHub, GitLab и т.п.). Если на удалении уже есть коммиты, которых нет локально, сервер отклонит простой push до синхронизации.

git pull по сути выполняет загрузку с удаления (git fetch) и затем объединение с вашей текущей веткой (git merge по умолчанию). Если нужно только узнать разницу, не вливая её сразу, достаточно git fetch, после чего можно сравнить, например: git diff origin/main или для привычного имени ветки — origin/master.

Ветки и конфликты при слиянии

Ветка — отдельная линия истории для задачи. Удобная привычка: под фичу создавать именованную ветку и не складывать её напрямую в основную линию, пока не пришло время выкладывать на продакшен.

Когда одни и те же строки правились в разных ветках, при merge Git помечает конфликт: в файле появляются маркеры с <<<<<<<, =======, >>>>>>>. Их нужно отредактировать вручную, оставив итоговый текст, затем проиндексировать файл (git add) и завершить коммитом. Если слияние начали по ошибке, откатить процесс можно командой git merge --abort.

Рабочий цикл со стендом под Битрикс

Перед крупной задачей имеет смысл на продакшене выполнить git status и убедиться, что нет неожиданных незакоммиченных файлов. На тестовом то же самое: если висят чужие изменения, разобраться по git diff — это правки только контента в шаблонах или логика и вёрстка; во втором случае лучше вернуть ответственному исполнителю нормальный коммит в своей ветке.

Когда рабочее дерево чистое, переключаемся на основную ветку (часто master или main), подтягиваем удаление и от неё создаём ветку задачи с понятным именем, например по номеру тикета в Битрикс24:

git checkout master
git pull
git checkout -b 1287.calendar_widget

Имя вроде pravki мало что объясняет при просмотре истории. Правки вносятся в рабочей копии на сервере (часто через SSH и удалённое монтирование в IDE), коммиты делаются там же, чтобы история совпадала с тем, что реально крутится на стенде.

Деплой через репозиторий

Типовая последовательность после ревью задачи: на продакшене снова проверить чистоту индекса, на тесте перейти на основную ветку и обновить её, влить ветку задачи, отправить результат на удаление и на продакшене выполнить pull.

# на тесте после проверки и ревью
git checkout master
git pull
git merge 1287.calendar_widget
git push
# на продакшене
git pull

Так оба контура остаются согласованы с общим эталоном на Git‑сервере; состояние «что задеплоено» проверяется коммитом, а не памятью о загруженных файлах.

Почему выкладка только через IDE или FTP плохо стыкуется с Git

Даже если вы закоммитили всё на тесте, но на прод залили файлы «как в прошлый раз» через клиент загрузки, на сервере появится набор изменённых файлов вне истории. Следующий разработчик увидит десятки незакоммиченных путей: неясно, что из этого уже в удалённом репозитории, что является аварийной правкой на месте и что нужно сохранить. Слияние собственной ветки с таким деревом часто упирается в конфликты или в вынужденный коммит с бессодержательным сообщением «Правки», который потом невозможно нормально отлаживать.

Универсальный выход — считать перенос на прод частью того же процесса, что и разработка: только через удалённый репозиторий, чтобы любой участник мог воспроизвести состояние веткой и коммитом.

Поиск коммита с регрессией: git bisect

Если баг «плавал» долго и откат на год назад его убирает, просматривать сотню коммитов вручную неудобно. Команда git bisect выполняет двоичный поиск между заведомо «плохой» текущей ревизией и «хорошей» старой (по хэшу коммита).

git bisect start
git bisect bad
git bisect good a1b2c3d4
# Git переключает промежуточные коммиты; после проверки сайта:
git bisect good   # бага нет
git bisect bad    # баг есть
git bisect reset  # по окончании

Если виноватым оказывается огромный коммит «Правки» без описания задачи, это снова аргумент в пользу атомарных коммитов с осмысленными сообщениями и выкладки только через понятную историю.

Дополнительные приёмы

Отмена уже попавшего в историю коммита

Для публичных веток предпочтительнее git revert <хэш>, который создаёт обратный коммит, не переписывая историю. Жёсткие git reset --hard на общих ветках лучше избегать без согласования с командой.

Перенос коммита в другую ветку

Если изменения оказались не в той ветке: в исходной откатить через git revert, в нужной выполнить git cherry-pick <хэш>.

Временно убрать незакоммиченное

git stash складывает текущие правки в стек; git stash apply возвращает их. Удобно, когда нужно быстро проверить исходное поведение сайта, не фиксируя недоделанный объём.

Сброс файла к последнему коммиту и очистка мусора

Для отдельного пути: git checkout -- путь/к/файлу. Для неотслеживаемых файлов смотрите git clean -nd (просмотр) и git clean -fd (удаление).

Исключение файла из индекса, не удаляя с диска

Если файл уже в репозитории, одного правила в .gitignore мало: сначала git rm --cached имя_файла, затем коммит. Имейте в виду: после такого коммита при git pull на другом сервере Git удалит этот путь из рабочей копии, если он больше не отслеживается — поведение осознанно согласуйте для всех окружений.

Кратко

Git на Битрикс‑проекте описывает код и шаблоны, а контент из админки живёт в базе — отсюда разные «источники правды». Регулярные pull/push, отдельные ветки под задачи и выкладка через тот же репозиторий снижают риск потерять файлы и делают историю пригодной для отладки и откатов.