Систему контроля версий (Version Control System, VCS) используют для того, чтобы с её помощью можно было отслеживать изменения в файловой системе или документах, и по необходимости сделать откат, чтобы видеть, кто и когда вносил правки и изменения.
Есть две основные VCS - это Git и Mercurial. В Mercurial более строгая система работы с ветками, поэтому для изучения и работы будем рассматривать Git.
Чтобы скачать Git, пройдите по ссылке https://git-scm.com/downloads и там выберите свою платформу (у нас это Windows, 64бита)
Также на сервере стоит установить Git. Для этого, подключившись по ssh, следует набрать команду:
apt install git (если у вас Debian) или
yum install git (если у вас CentOS)
Для того, чтобы работать с VCS, нужно где-то хранить данные, создать так называемый репозиторий (ресурс, хранилище - для каждого сайта-проекта создается свой).
Если вам можно выложить код на всеобщее обозрение - Вы можете воспользоваться, например, тем же самым GitHabом. Если вам нужно защитить код от лишних глаз – рекомендую создавать приватные репозитории в https://bitbucket.org/
Разумеется, можно объединяться и работать в команде, дав доступ к ресурсу другому разработчику, зарегистрированному на bitbucket`e. Эту систему мы дальше и будем рассматривать в статье. При регистрации советую подобрать недлинный, но непростой пароль, т.к. при каждой заливке в целях безопасности следует набирать его.
В отличие от обычной заливки по FTP, при использовании VCS все изменения сначала выливаются в репозиторий, а только затем из хранилища - на рабочий сайт.
Разумеется, можно вылить сначала на тестовый сервер, всё это протестировать, и только потом уже вливать на рабочий (боевой) сайт.
Сразу возникает вопрос - а как же быть с базой данных?
Конечно, этот момент зависит от используемой CMS. В целом, наиболее практичной показал себя вариант с развертыванием базы на тестовом сервере. Данная база смотрит на внешку и позволяет подключаться с локалки (это облегчает тестирование и актуализацию информации). Правда, у этого способа есть минус - после окончания внесения изменений нужно также все изменения из БД переносить на боевой сайт, что иногда проблематично.
Поэтому можно использовать базу с боевого сервера, только нужно быть аккуратным при разработке, т.к. изменения в базе уже проведены, а код пока лишь у вас на "локалке". Также есть вариант развернуть базу на локалке, но в любом случае её придется в итоге переносить (или частично вносить изменения в тестовую и боевую базу)
Сразу оговорюсь: планируется отдельная статья по открытию доступа к базе с "внешки" - т.к. для этого необходимо соблюсти несколько условий. Открытый порт (3306 по-умолчанию) для сервера mysql, в настройках сервера mysql он должен смотреть на все интерфейсы (а не только на localhost), а также нужно установить хост пользователя в % вместо localhost.
Итак, после установки GIT создадим репозиторий. В интерфейсе bitbucket можно без проблем создать тот же репозиторий, и даже отдельную ветку для него прямо на сайте.
Слева в меню есть: + далее выбираем Repository.
Задаем имя ресурсу, выбираем, будет ли он приватным. Через галочку "Это приватный репозиторий".
В созданном репозитории можно сразу создать ветку develop - в ней будет производиться вся разработка, а затем изменения можно будет заливать в основную ветку (master).
Далее, нужно установить связь локалки и репозитория. Есть множество клиентов GIT с визуальным интерфейсом, но наиболее удобно работать с ним прямо из среды разработки (IDE). В нашем случае, в качестве IDE будем использовать PHPStorm.
Для phpstorm есть специальный плагин Bitbucket Linky - который позволяет взаимодействовать нам с репозиториями.
Также не забываем указать путь к установленному файлу git.exe в File->Settings->Version Control->Git
Если git вам ответил, что репозиторий не найден - самое время его создать командой git init
Далее, если вам нужно добавить файлы сайта в репозиторий - заходим по ssh, переходим в корневую папку сайта и проверяем текущий статус командой git status
Затем нужно настроить игнорируемые файлы и папки (untrackable), которые не должны попадать в репозиторий. Список зависит от используемой CMS (найти и прикрепить примеры для популярных CMS). Настраивается список в файле .gitignore в корне папки (например командой nano .gitignore).
После настройки файла .gitignore добавляем файлы в репозиторий командой git add . (точка в данном случае будет указывать на все файлы).
Далее указываем удаленный репозиторий путем редактирования файла .git/config
в нем в строках:
[remote "origin"]
url = https://username@bitbucket.org/test.git указываем URL нашего репозитория (его можно взять, нажав на кнопку "Клонировать" на сайте bitbucket в нужном репозитории и вырезав сам url)
Далее фиксируем наше первое изменение командой git commit -m "initial commit"
И выливаем изменение в репозиторий командой git push origin master
Далее на локалке можно очень легко взять содержимое репозитория - в phpstorm даже при создании проекта можно указать тот же URL и он автоматически скачает его.
Важно указать правильную папку (для связки с openserverом), чтобы можно было запускать сайт на локалке. Также советую добавить в .gitignore файл .htaccess и заливать его "по-старинке", а также папку с пользовательским контентом, которая меняется при заполнении сайта контентом (для битрикса это папка upload). Это позволит не добавлять контент в репозиторий каждый раз при его изменении, а также можно настроить отображении картинок на локалке, прописав в htaccess подобную строку: RewriteRule ^upload/(.*)$ http://mysite.ru/upload/$1 [R=301,L]
На этом пока всё. Основные нужные при работе команды мы опишем в следующей статье.
Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.