Лет 5 назад я работал с системой контроля версий - это была SVN. Такая себя громоздкая и неповоротливая. Но все же система контроля версий.
И вот на новом месте работы появилась потребность на крупных проектах вводить релизную систему, т.е. необходимо настраивать систему контроля версий, заводить репозитории и т.д.
Очень пугала неизвестность, т.к. практического опыта работы с mercurial или git не было. И из-за этого вопрос всё откладывался и откладывался...
Но на практике оказалось, что всё достаточно просто и с этим вопросом (при отсутствии знаний Git совсем) можно разобраться за пару дней, а с наличием знаний и вовсе за час-два.
В своем посте хочу привести пример настройки репозитория в самом простом варианте.
Зачем вам репозиторий? Если у вас нет репозитория, то ваша работа с сайтом, это как операция на открытом сердце. Любая ваша ошибка нарушает работоспособность сайта. Пока сайт в разработке, это вроде некритично, но вот после запуска - это становится огромной проблемой!
Приведу два примера
Пример 1 Есть одна виртуальная машина или сервер (это не важно для нас сейчас). В папке /home/bitrix/www - располагается файловая структура вашего сайта, например, site.com. Для разработки нам необходима копия сайта /home/bitrix/ext_www/dev.site.com, на домене dev.site.com В обеих папках у нас будут локальные репозитории Git, которые будут работать с удаленным репозиторием.
Пример 2 Отличается тем, что файловая структура сайтов лежит на разных серверах. Например, сервер 1 /home/bitrix/www, site.com сервер 2 /home/bitrix/www, dev.site.com
Настройка репозиториев
1. Проверяем есть ли у нас Git На виртуальной машине версии 5 все уже установлено. Подключаетесь к вашему серверу по ssh, авторизовываетесь под пользователем bitrix и вводите команду
>git
Если вы увидели вывод информации о гит, все нормально. Если сообщение, что команда системе не известна, тогда понадобится проинсталировать пакет. В этом посте я этот вопрос рассматривать не буду.
Если Вы проводили инсталяцию git самостоятельно, то не забудьте запретить доступ к папка git вашего сайта в настройках nginx и apache (htaccess).
2. Настраиваете файл .gitignore Создаете в корне сайта файл .gitignore и настраиваете его. Приведу пример, в котором мы исключаем из репозитория все что относится к ядру сайта и включаем, только то что нужно. Коллеги в комментариях подсказали, что можно и вовсе исключить из индекса папку bitrix, для этого нужно использовать папку /local
/.gitignore
/.htaccess
/*.htaccess
/.htaccess*
/urlrewrite.php
/web.config
/*web.config
/*.log
/*.sql
# исключаем из репозитория текстовые файлы, но оставляем robots.txt
/*.txt
!/robots.txt
/sitemap*.xml
/*.dt
/*.tar.gz
/*.gz
/*.tar
/*.bak
/*.old
/*~
*/_*
/_*
/composer.*
# исключаем ВСЮ папку bitrix, но ниже настроим включение нужных папок
# или используйте папку /local, чтобы полностью исключить папку bitrix
/bitrix/*
# включаем папку components, но исключаем components/bitrix
!/bitrix/components
/bitrix/components/bitrix/
# включаем папку php_interface и исключаем файл dbconn.php
!/bitrix/php_interface/
/bitrix/php_interface/dbconn.php
/bitrix/php_interface/*.bak
# включаем папку шаблонов
!/bitrix/templates/
# исключаем служебные и ненужные папки проекта
/dev
/pma
/upload
/verstka
3. Инициализируем репозиторий В командной строке переходите в домашний каталог, в котором лежит ваша папка сайта
>cd /home/bitrix
Инициализируем репозиторий в папке www
>git init www
4. Начинаем работу с локальным репозиторием Чтобы посмотреть что и как у вас настроено Переходите в папку сайта
>cd /home/bitrix/www
Проверяете состояние репозитория
>git status
В результате вы увидите список файлов и папок, которые попадут в репозиторий. Как раз сейчас самое время внести корректировки в файл .gitignore Добавьте или уберите исключения, которые нужны именно для вашего проекта. Если надо проверить индексацию внутри папки сайта, например /bitrix, используйте
>git status bitrix
5. Добавляем файлы в репозиторий После того как вы настроили игнорирование и включение в репозиторий и убедились, что в хранилище попадет только то, что вам необходимо, самое время добавить файлы в репозиторий и сделать первый коммит. Убедитесь что вы в папке вашего сайта
>cd /home/bitrix/www
Файлы можно добавлять выборочно с помощью команды
>git add index.php
Или все сразу
>git add .
После этого можете проверить, что все файлы будут проиндексированы
>git status
на экране будет сообщение, что все проидексировано. Можно делать первый коммит
>git commit -m "first commit"
6. Настройка удаленного репозитория После того как вы настроили работу репозитория локально, надо выгрузить хранилище на сервер. В качестве сервера можно выбрать https://bitbucket.org/ Бесплатный сервис, который предоставляет приватные репозитории. Вы можете выбрать любой сервис, который вам больше по душе. Настройка авторизации на этих сервисах отлично опасана в интернетах, поэтому я не буду раздувать пост и приведу основные команды для настройки начала работы.
Для начала нам понадобится сгенерировать ssh-ключи Это делается командой
>ssh-keygen -t rsa -C "bitrix@имя.сайта"
По умолчанию, если ничего не будете менять, этой командой вы сгенерируете два ключа, приватный id_rsa и публичный id_rsa.pub они будут в папке /home/bitrix/.ssh/
Далее вам нужно взять содержимое публичного ключа и вставить в настройки аккаунта bitbucket.org Вы можете открыть файл приватного ключа в редакторе кода и скопировать одной строкой его содержимое. Или вывести на экран содержимое файла командой
>cat ~/.ssh/id_rsa.pub
Важное замечание! Ключ в bitbucket нужно вставлять в настройках вашего профиля, а не репозитория!
После того как вы настроили ключи, проверьте соединение
>ssh -T git@bitbucket.org
В результате вы должны увидеть сообщение об успешно коннекте к сервису.
Если увидите ошибку, то выполняйте соединение с выводом логов
>ssh -v git@bitbucket.org
или
>ssh -vvv git@bitbucket.org
Возможно проблема, что сгенерированный ключ не будет использоватся для авторизации, тогда покажите ваш приватный ключ системе
>ssh-agent /bin/bash
>ssh-add ~/.ssh/id_rsa
и проверьте соединение еще раз
>ssh -v git@bitbucket.org
Теперь все должно быть хорошо!
7. Передача синхронизация репозитория Сервисы тоже отлично подсказывают как синхронизировать репозитории и выдают команды для вашего проекта, поэтому так же кратко.
В локальном репозитории, нужно добавить связь с удаленным репозиторием
your_company - ваш логин bitbucket.org your_repo - название вашего репозитория в bitbucket.org
Т.к. локальный репозиторий уже подготовлен, то нам осталось его передать в удаленное хранилище
>git push origin master
Этой командой вы отправите вашу основную ветку master из локального в удаленный репозиторий. После вывода сообщения что все закончилось хорого, вы можете пойти в репозиторий bitbucket и полюбоваться структурой папок и файлов через браузер.
8. Настройка второго локального репозитория На данном этапе у нас готовы - локальный репозиторий (обычно это боевой сайт или сайт после разработки, который вот вот станет боевым) - и удаленный репозиторий Т.е. нам не хватает заключающего репозитория для нашей разработки.
Если вы настраиваете репозитории, имея одну рабочую копию сайта, то вам достаточно будет скопировать файловую структуру, это и будет вторым готовым к работе репозиторием. Кратко о процессе: 1. Создаете дополнительный сайт на виртуальной машине с помощью меню виртуальной машины 2. В папку созданного сайта копируете всю структуру
В результате у вас появится файл /home/bitrix/site.com.tar.gz со структурой вашего сайта, который вы можете скопировать на новый сервере и там развернуть
>tar -xf site.com.tar.gz
9. Заключение В итоге мы настроили 1. Локальный репозиторий продакшен сайта /home/bitrix/www 2. Удаленный репозиторий на bitbucket 3. Локальный репозиторий сайта разработки /home/bitrix/ext_www/dev.site.com или папка на другом сервере
Схема работы следущая: 1. Вся разработка ведется на сайте разработки 2. Все изменения отслеживаются командой
>cd /home/bitrix/ext_www/dev.site.com
>git status
3. Все изменения фиксируются командами
>cd /home/bitrix/ext_www/dev.site.com
>git add
и
>git commit
4. Все зафиксированные изменения выгружаются в удаленный репозиторий
I) Как указали выше, папку .git лучше располагать на уровень выше корня сайта. Это не только понизит шансы утечки содержимого .git, но и позволит контролировать служебные механизмы, которым не место в корневом каталоге и подкаталогах сайта: скрипты для запуска по расписанию, unit-тесты и пр.
II) Папку bitrix не стоит включать в .gitignore, так как если не контролировать ядро Битрикс, то:
1. Разработчикам будет уже недостаточно просто склонировать репозиторий для начала работы. Придется добывать недостающие файлы. Причем, если работа над проектом ведется несколько лет, его состояние редко позволит использовать "cp -r", как указано в статье. Как показывает опыт, вместо этого придется заниматься трудоемким избирательным копированием.
2. Разработчики бывают разными и сколько не запрещай, в команде обязательно найдется человек, который поправит что-нибудь в ядре. В этом случае, появляется шанс, что в продуктивную среду уйдет код, который приведет к аварии. Это возможно, если код активно использует измененное ядро, а тестирование функциональности проводилось только на копии этого разработчика.
Если включить файлы ядра в систему контроля версий, то изменения в файлах ядра становится возможным отслеживать и автоматически запрещать на уровне перехватчиков (hooks). Также можно настроить отправку уведомлений таким разработчикам с напоминанием правил работы с Битрикс.
3. Недопустимыми правками часто не брезгуют и операторы заказчика. Если не контролировать файлы ядра, такие изменения в продуктивной среде становится трудно отследить. Хоть Битрикс и сделал для этого собственный инструмент, Git в таких случаях помогает гораздо надежней.
4. Если не контролировать ядро, актуализировать файлы на всех копиях разработки после обновления Битрикс может стать очень затруднительно. Особенно, когда число таких копий приближается к сотне.
5. Порой, очередное обновление Битрикс приводит к ошибкам в существующей функциональности. Git показывает пришедшие с обновлением изменения, что существенно облегчает поиск проблем в таких случаях.
6. Не существует ни одной объективной причины, почему ядро нужно исключать из контроля версий. Многие опасаются, что производительность Git существенно упадет из-за количества файлов в каталоге bitrix. Это напрасное опасение — практика показывает, что Git прекрасно справляется с этой задачей.
III) Не стоит использовать сторонние сервисы (BitBucket, GitHub и прочие) для чужих коммерческих проектов. Это часто противоречит требованиям NDA, может стать причиной утечек кода, а также, учитывая последние законодательные тенденции, и вовсе однажды оказаться незаконным.
В качестве отрицательного примера можно привести блокировку GitHub на несколько дней в начале декабря. Некоторым компаниям это едва ли не парализовало работу.
При этом, для того чтобы сделать центральный репозиторий, достаточно выбрать подходящий сервер (желательно внутри сети) и набрать там команду git init --bare. И все. В итоге, получается полноценный репозиторий, доступ к которому всегда находится под полным контролем.
Кроме того, собственный центральный репозиторий позволяет гибко управлять обвесом: выбирать любимые протоколы, веб-интерфейсы, системы контроля доступа и рабочие процессы.
Вообще как то все получилось, но из-за того что все делается под пользователем bitrix на сервере не создаются эти файлы при первом заливе [bitrix@eurекеекn www]$ git push origin master error: unable to create directory for .git/refs/remotes/origin/master error: Cannot lock the ref 'refs/remotes/origin/master'.
Макаров Евгений, а вы репозиторий инициировали (git init) по рутом? Если да, то ничего удивительного, теперь у пользователя bitrix не хватает прав для работы с репозиторием.
Если Вы проводили инсталяцию git самостоятельно, то не забудьте запретить доступ к папка git вашего сайта в настройках nginx и apache (htaccess). Как закрыть можно рабочий кусочек кода для biitrixVM 7.3.3
Все-таки в видео более рабочая схема придумана: Песочницы для разработчиков (сколько угодно) -> Коммиты в репозитарий -> Pull на Предпродакшн -> Pull на Продакшн
Но Ваша статья, наряду с несколькими часами поиска информации в интернете очень посбособствовали пониманию и развертыванию полноценной рабочей среды, с системой контроля версий и правами доступа для неограниченного числа разработчиков.
Салиев Вячеслав, благодарю. Очень рад, что моя статья полезна и через 4 года после её написания. И да, статья - это вводная в работу с репозиторием. В реальности приходится работать с более сложными схемами.
Угрюмова Юлия, очень мало информации о вашем вопросе, чтобы на него ответить. но могу попробовать поугадывать: - если все делали по инструкции в статье, то авторизация идет по ssh ключу. И скорее всего просит кодовую фразу к ключу, которую вы указывали при генерации ключа. - может просить логин/пароль пользователя с правами доступа к репозиторию - может тянется непонятный ключ и что-то просит
Яковенко Дмитрий, делала всё по инструкции. Вводила пароль для ssh, вводила пароль root, вводила пароль от ЛК в bitbucket. Пробовала оставлять пустым. Ничего не получатся, выводит текст о том, что нет доступа.
Угрюмова Юлия, вы добавили линк на репозиторий с чужим логином, я не знаю где вы его взяли. обычно в битбакете в самом репозитории есть кнопка клонировать и там есть линк в 2х форматах: ssh и https.
вы можете изменить адрес git remote set-url origin git://new.url.here
или удалить git remote delete origin И добавить по новой
Коллеги, подскажите видел статью, но потерял её и не могу найти. Что надо сделать что бы в гит так же улетала информация при изменении страницы через CMS Bitrix когда меняешь страничку "Изменить в режиме PHP кода". Это ведь реализуемо ?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».