Полное руководство: Синхронизация «живого» сайта на Битриксе с GitHub

Задача: У нас есть «живой» сайт на Bitrix, который находится на удаленном сервере. История его разработки неизвестна, а контроль версий (Git) не велся. Наша цель — забрать актуальную версию сайта с сервера, инициализировать для него Git-репозиторий и выгрузить его в качестве основной версии на GitHub, решив по пути все возможные проблемы.

Инструменты:

• Набор скриптов Bitrix Developer Toolkit.

• SSH-доступ к удаленному серверу.

• Аккаунт на GitHub.

---

Шаг 1: Первая попытка синхронизации и диагностика

Мы запустили скрипт синхронизации, но столкнулись с проблемой: скрипт подключался к серверу, но не скачивал ни одной папки (local, bitrix/templates и т.д.), хотя мы точно знали, что они существуют.

Это классический симптом одной из двух проблем:

• Некорректные права доступа на сервере.

• Ошибки в логике самого скрипта синхронизации.

Как показало расследование, верными оказались оба пункта.

1.1. Исправление прав доступа на сервере

Первым делом мы подключились к серверу по SSH и проверили права на папку проекта с помощью команды ls -la /home/bitrix/www/.

Вывод показал корень проблемы:

drwx------ 10 bitrix bitrix 4096 Oct 21 09:14 ..

Родительская директория /home/bitrix имела права 700 (drwx------), что запрещало любым сторонним процессам (включая rsync, который использует скрипт) даже “войти” в нее, чтобы добраться до папки www.

Решение: Мы исправили права на сервере, приведя их к безопасному стандарту.

# 1. Разрешаем "транзит" через домашнюю директорию, не давая прав на чтение ее содержимого.
# Это безопасно и необходимо для работы многих системных утилит.
sudo chmod o+x /home/bitrix

# 2. Рекурсивно устанавливаем стандартные права для веб-проектов:
# 755 для папок (владелец может всё, остальные — читать и входить)
sudo find /home/bitrix/www -type d -exec chmod 755 {} \;

# 644 для файлов (владелец может читать/писать, остальные — только читать)
sudo find /home/bitrix/www -type f -exec chmod 644 {} \;

1.2. Улучшение скрипта синхронизации

После исправления прав мы запустили скрипт снова и получили новые, более осмысленные ошибки:

• No such file or directory для папки /local.

• No such file or directory при попытке создать /bitrix/php_interface на локальной машине.

Диагноз:

• На сервере действительно не было папки local, что нормально для многих проектов.

• Скрипт пытался скопировать bitrix/php_interface в несуществующую на тот момент локальную папку bitrix.

Решение: Мы внесли изменения в скрипт rsync-transfer.sh, чтобы он стал более “умным”:

• Перед копированием вложенных папок (php_interface, templates) он теперь принудительно создает родительскую директорию mkdir -p "$LOCAL_BASE/bitrix".

• Он больше не показывает ошибку, если папка /local отсутствует, а просто выводит предупреждение.

После этих исправлений синхронизация файлов прошла успешно.

---

Шаг 2: Работа с Git и синхронизация с GitHub

Проект был успешно скачан, и скрипт инициализировал для него новый, чистый Git-репозиторий. Старая история коммитов (если она была) нас не интересовала, так как мы брали за основу актуальное состояние сайта.

При попытке выгрузить изменения на GitHub мы столкнулись с двумя классическими проблемами.

2.1. Ошибка Permission denied (publickey)

При выполнении команды git push мы получили отказ в доступе.

Причина: SSH-ключ, который использовался на нашей машине для аутентификации, не был добавлен в наш аккаунт на GitHub. GitHub просто “не знал” наш компьютер.

Решение:

• Мы скопировали содержимое нашего публичного ключа:

cat ~/.ssh/id_rsa.pub

• Перешли в настройки аккаунта GitHub в раздел SSH and GPG keys.

• Нажали “New SSH key” и вставили скопированный ключ.

2.2. Расхождение историй и git push --force

Так как локально у нас был абсолютно новый репозиторий с одним коммитом, а на GitHub — старый репозиторий с другой историей, обычный git push не сработал бы.

Решение: Мы использовали принудительную отправку (force push), чтобы полностью перезаписать историю на GitHub нашей новой, актуальной версией.

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

git push -u origin main --force

---

Шаг 3: Финальная чистка: main против master

После force push в нашем репозитории на GitHub оказалось две главные ветки:

• master (старая ветка по умолчанию изначального репозитория).

• main (новая ветка, которую мы только что отправили).

Решение: Мы оставили только одну актуальную ветку main.

• Смена ветки по умолчанию: В настройках репозитория на GitHub (по ссылке https://github.com/USER/REPO/settings) мы изменили “Default branch” с master на main.

• Удаление старой ветки: После этого мы выполнили команду в терминале, чтобы удалить ненужную ветку master с удаленного сервера:

git push origin --delete master

Итог

Пройдя через все эти шаги, мы добились цели:

• Актуальная версия сайта с «боевого» сервера теперь находится на нашей локальной машине.

• Для проекта инициализирован чистый Git-репозиторий.

• Проект выгружен на GitHub, имеет правильную структуру веток и готов к дальнейшей цивилизованной разработке с использованием контроля версий.