Лет 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. И все. В итоге, получается полноценный репозиторий, доступ к которому всегда находится под полным контролем.
Кроме того, собственный центральный репозиторий позволяет гибко управлять обвесом: выбирать любимые протоколы, веб-интерфейсы, системы контроля доступа и рабочие процессы.
3. Не плохо подчеркнуть, что таким образом при помощи GIT деплоиться будут только исходные коды, а о переносе на рабочий сайт изменений в инфоблоках надо заботиться отдельно; в Маркетплейсе для этого есть некоторые решения, например, http://marketplace.1c-bitrix.ru/solut...igrations/ для автоматизации создания миграций БД, но все равно без ручной работы пока тут не обойтись.
4. Стоит отметить, что на практике вместо прямого коммита в мастер-ветку, особенно в случае, когда над проектом работает команда, договориться о процессе (своем или, например, использовать git flow), который накладывает табу на прямой коммит в мастер, а каждый работает в своей ветке и используется механизм pull-реквестов. В самом простом варианте процесса перед выпуском релиза и деплоем на продакшн ответственный объединяет ветки и сливает изменения в мастер.
1 - НУЖНО использовать папку local, и тогда в гитигнор уйдёт /bitrix, это правильно и удобно 2 - под гит надо класть не папку www, а папку на уровень выше. Это накладывает определённые требования на работу с деплой-сервером, но более перспективно.
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. И все. В итоге, получается полноценный репозиторий, доступ к которому всегда находится под полным контролем.
Кроме того, собственный центральный репозиторий позволяет гибко управлять обвесом: выбирать любимые протоколы, веб-интерфейсы, системы контроля доступа и рабочие процессы.
Кунташов Александр написал: Поскольку статья рассчитана скорее на начинающих
Именно на них, чтобы не боялись и сделали первый шаг.
Кунташов Александр написал: 1. Если для GIT использовать для деплоя, как описано в статье, то надо защитить каталог .git при помощи .htaccess, чтобы он не было доступен публично.
В посте я говорю о вирт. машине битрикса, в ее конфигах папки .git закрыты для доступа. Но добавлю пометку, чтобы не забыли при самостоятельной инсталяции гита.
Кунташов Александр написал: 4. Стоит отметить, что на практике вместо прямого коммита в мастер-ветку, особенно в случае, когда над проектом работает команда, договориться о процессе (своем или, например, использовать git flow), который накладывает табу на прямой коммит в мастер, а каждый работает в своей ветке и используется механизм pull-реквестов. В самом простом варианте процесса перед выпуском релиза и деплоем на продакшн ответственный объединяет ветки и сливает изменения в мастер.
С вами согласен, но из-за пункта 1 в вашем комментарии, я ни слова не говорил в посте про ветки
Цупко Игорь написал: 2 - под гит надо класть не папку www, а папку на уровень выше. Это накладывает определённые требования на работу с деплой-сервером, но более перспективно.
Иван написал: 6. Не существует ни одной объективной причины, почему ядро нужно исключать из контроля версий. Многие опасаются, что производительность Git существенно упадет из-за количества файлов в каталоге bitrix. Это напрасное опасение — практика показывает, что Git прекрасно справляется с этой задачей.
У меня тоже были эти опасения. Спасибо, что поделились своим опытом!
Все-таки, чтобы не быть голословным, приведу пример одного из проектов:
Это очень большой репозиторий — его размер в 19 раз превосходит размер репозитория среднего проекта на Битрикс (с ядром). Число контролируемых файлов также более чем в три раза выше обычного.
При этом, время выполнения одной из самых долгих команд (status) не превысило пяти секунд на "холодных" файлах и составило менее секунды уже при повторном запуске. И это на машине с довольно медленными дисками.
Я не особо знаком с git. Задам такой вопрос, может быть глупый. А как с git уживаются простые контент-редакторы, которые правят текстовые страницы через визуальный редактор Битрикса? Или редактирование файлов через виз.редактор полностью запрещается? У меня есть клиент, на сервере которого именно так и сделано. Как-то не очень удобно я считаю.
По поводу не использования github и т.п. У меня на внутреннем сервере развернут gitlab, по сути аналог github, который можно поднять на своем железе - очень рекомендую. Поднимается за час-два на живом сервере, или за 5-10 минут если есть возможность поднять под него чистую виртуалку, или 1 минута если разворачивать на digitalocean =)
Иван, согласен с приведёнными примерами, но всё же тогда bitrix надо класть под отдельный git, и/или подключать субмодулем. Причина проста: обновления.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».