Лет 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 вашего сайта в настройках nginx и apache (htaccess).
2. Настраиваете файл .gitignore
Создаете в корне сайта файл .gitignore и настраиваете его.
Приведу пример, в котором мы исключаем из репозитория все что относится к ядру сайта и включаем, только то что нужно.
Коллеги в комментариях подсказали, что можно и вовсе исключить из индекса папку bitrix, для этого
3. Инициализируем репозиторий
В командной строке переходите в домашний каталог, в котором лежит ваша папка сайта
Инициализируем репозиторий в папке www
4. Начинаем работу с локальным репозиторием
Чтобы посмотреть что и как у вас настроено
Переходите в папку сайта
Проверяете состояние репозитория
В результате вы увидите список файлов и папок, которые попадут в репозиторий.
Как раз сейчас самое время внести корректировки в файл .gitignore
Добавьте или уберите исключения, которые нужны именно для вашего проекта.
Если надо проверить индексацию внутри папки сайта, например /bitrix, используйте
5. Добавляем файлы в репозиторий
После того как вы настроили игнорирование и включение в репозиторий и убедились, что в хранилище попадет только то, что вам необходимо, самое время добавить файлы в репозиторий и сделать первый коммит.
Убедитесь что вы в папке вашего сайта
Файлы можно добавлять выборочно с помощью команды
Или все сразу
После этого можете проверить, что все файлы будут проиндексированы
на экране будет сообщение, что все проидексировано.
Можно делать первый коммит
6. Настройка удаленного репозитория
После того как вы настроили работу репозитория локально, надо выгрузить хранилище на сервер.
В качестве сервера можно выбрать
Бесплатный сервис, который предоставляет приватные репозитории.
Вы можете выбрать любой сервис, который вам больше по душе.
Настройка авторизации на этих сервисах отлично опасана в интернетах, поэтому я не буду раздувать пост и приведу основные команды для настройки начала работы.
Для начала нам понадобится сгенерировать ssh-ключи
Это делается командой
По умолчанию, если ничего не будете менять, этой командой вы сгенерируете два ключа, приватный id_rsa и публичный id_rsa.pub
они будут в папке /home/bitrix/.ssh/
Далее вам нужно взять содержимое публичного ключа и вставить в настройки аккаунта bitbucket.org
Вы можете открыть файл приватного ключа в редакторе кода и скопировать одной строкой его содержимое. Или вывести на экран содержимое файла командой
Важное замечание! Ключ в bitbucket нужно вставлять в настройках вашего профиля, а не репозитория!
После того как вы настроили ключи, проверьте соединение
В результате вы должны увидеть сообщение об успешно коннекте к сервису.
Если увидите ошибку, то выполняйте соединение с выводом логов
или
Возможно проблема, что сгенерированный ключ не будет использоватся для авторизации, тогда покажите ваш приватный ключ системе
и проверьте соединение еще раз
Теперь все должно быть хорошо!
7. Передача синхронизация репозитория
Сервисы тоже отлично подсказывают как синхронизировать репозитории и выдают команды для вашего проекта, поэтому так же кратко.
В локальном репозитории, нужно добавить связь с удаленным репозиторием
your_company - ваш логин bitbucket.org
your_repo - название вашего репозитория в bitbucket.org
Т.к. локальный репозиторий уже подготовлен, то нам осталось его передать в удаленное хранилище
Этой командой вы отправите вашу основную ветку master из локального в удаленный репозиторий.
После вывода сообщения что все закончилось хорого, вы можете пойти в репозиторий bitbucket и полюбоваться структурой папок и файлов через браузер.
8. Настройка второго локального репозитория
На данном этапе у нас готовы
- локальный репозиторий (обычно это боевой сайт или сайт после разработки, который вот вот станет боевым)
- и удаленный репозиторий
Т.е. нам не хватает заключающего репозитория для нашей разработки.
Если вы настраиваете репозитории, имея одну рабочую копию сайта, то вам достаточно будет скопировать файловую структуру, это и будет вторым готовым к работе репозиторием.
Кратко о процессе:
1. Создаете дополнительный сайт на виртуальной машине с помощью меню виртуальной машины
2. В папку созданного сайта копируете всю структуру
Если у вас второй сервер, то сверните файлы и скопируйте их на новый сервер
В результате у вас появится файл /home/bitrix/site.com.tar.gz со структурой вашего сайта, который вы можете скопировать на новый сервере и там развернуть
9. Заключение
В итоге мы настроили
1. Локальный репозиторий продакшен сайта
/home/bitrix/www
2. Удаленный репозиторий на bitbucket
3. Локальный репозиторий сайта разработки
/home/bitrix/ext_www/dev.site.com или папка на другом сервере
Схема работы следущая:
1. Вся разработка ведется на сайте разработки
2. Все изменения отслеживаются командой
3. Все изменения фиксируются командами
и
4. Все зафиксированные изменения выгружаются в удаленный репозиторий
5. Зафиксированные изменения загружаются в репозиторий продакшен сайта
Готово!
Update: полезное видео по теме
10. Выводы и использованная литература
Быстро, всего за 9 шагов, можно настроить самую простую работу с репозиториями и сильно упростить себе жизнь.
По поводу работы с системой Git
Такая себя громоздкая и неповоротливая. Но все же система контроля версий.
И вот на новом месте работы появилась потребность на крупных проектах вводить релизную систему, т.е. необходимо настраивать систему контроля версий, заводить репозитории и т.д.
Очень пугала неизвестность, т.к. практического опыта работы с 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, для этого
/.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 |
В командной строке переходите в домашний каталог, в котором лежит ваша папка сайта
>cd /home/bitrix |
>git init www |
Чтобы посмотреть что и как у вас настроено
Переходите в папку сайта
>cd /home/bitrix/www |
>git status |
Как раз сейчас самое время внести корректировки в файл .gitignore
Добавьте или уберите исключения, которые нужны именно для вашего проекта.
Если надо проверить индексацию внутри папки сайта, например /bitrix, используйте
>git status bitrix |
После того как вы настроили игнорирование и включение в репозиторий и убедились, что в хранилище попадет только то, что вам необходимо, самое время добавить файлы в репозиторий и сделать первый коммит.
Убедитесь что вы в папке вашего сайта
>cd /home/bitrix/www |
>git add index.php |
>git add . |
>git status |
Можно делать первый коммит
>git commit -m "first commit" |
После того как вы настроили работу репозитория локально, надо выгрузить хранилище на сервер.
В качестве сервера можно выбрать
Бесплатный сервис, который предоставляет приватные репозитории.
Вы можете выбрать любой сервис, который вам больше по душе.
Настройка авторизации на этих сервисах отлично опасана в интернетах, поэтому я не буду раздувать пост и приведу основные команды для настройки начала работы.
Для начала нам понадобится сгенерировать ssh-ключи
Это делается командой
>ssh-keygen -t rsa -C "bitrix@имя.сайта" |
они будут в папке /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. Передача синхронизация репозитория
Сервисы тоже отлично подсказывают как синхронизировать репозитории и выдают команды для вашего проекта, поэтому так же кратко.
В локальном репозитории, нужно добавить связь с удаленным репозиторием
>cd /home/bitrix/www/ >git remote add origin git@bitbucket.org:your_company/your_repo |
your_repo - название вашего репозитория в bitbucket.org
Т.к. локальный репозиторий уже подготовлен, то нам осталось его передать в удаленное хранилище
>git push origin master |
После вывода сообщения что все закончилось хорого, вы можете пойти в репозиторий bitbucket и полюбоваться структурой папок и файлов через браузер.
8. Настройка второго локального репозитория
На данном этапе у нас готовы
- локальный репозиторий (обычно это боевой сайт или сайт после разработки, который вот вот станет боевым)
- и удаленный репозиторий
Т.е. нам не хватает заключающего репозитория для нашей разработки.
Если вы настраиваете репозитории, имея одну рабочую копию сайта, то вам достаточно будет скопировать файловую структуру, это и будет вторым готовым к работе репозиторием.
Кратко о процессе:
1. Создаете дополнительный сайт на виртуальной машине с помощью меню виртуальной машины
2. В папку созданного сайта копируете всю структуру
>cd /home/bitrix/www >cp -r . /home/bitrix/ext_www/dev.site.com/ |
>cd /home/bitrix/www >tar -cf /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 |
>cd /home/bitrix/ext_www/dev.site.com >git add |
>git commit |
>cd /home/bitrix/ext_www/dev.site.com >git push origin master |
>cd /home/bitrix/www >git pull origin master |
Готово!
Update: полезное видео по теме
10. Выводы и использованная литература
Быстро, всего за 9 шагов, можно настроить самую простую работу с репозиториями и сильно упростить себе жизнь.
По поводу работы с системой Git
- рекомендую ознакомится с книгой-документацией, очень понятная и полезная
или (тут не все на русском) - Великолепная шпаргалка по командам GIT:
- Ежедневная работа с Git
- Моя шпаргалка по работе с Git
- Организация командной разработки интернет-проекта (с использованием Git и 1С-Битрикс)
- Ежедневный Git
| 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, может стать причиной утечек кода, а также, учитывая последние законодательные тенденции, и вовсе однажды оказаться незаконным. В качестве отрицательного примера можно привести на несколько дней в начале декабря. Некоторым компаниям это едва ли не парализовало работу. При этом, для того чтобы сделать центральный репозиторий, достаточно выбрать подходящий сервер (желательно внутри сети) и набрать там команду git init --bare. И все. В итоге, получается полноценный репозиторий, доступ к которому всегда находится под полным контролем. Кроме того, собственный центральный репозиторий позволяет гибко управлять обвесом: выбирать любимые протоколы, веб-интерфейсы, системы контроля доступа и рабочие процессы. |
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
