Подключаем Git к проекту WordPress

Всем привет! Наверное, соскучились без моей писанины? =) Ладно-ладно, не отвечайте – знаю, что соскучились =)

С некоторых пор, для всех новых проектов я использую систему контроля версий git. Это уже стало стандартом для разработчиков и, практически, во всех вакансиях на должность веб-программиста требуется обязательное или желательное знание git.

Вот, наконец-то, и свой блог решил перевести на “рельсы” git. Собственно, в этой статье и опишу как подключить git к действующему проекту WordPress и какие это даст удобства для разработчика или администратора блога. Скорей всего, эту инструкцию можно будет применить и для других CMS, фреймворков и т.п., но здесь будут нюансы, касающиеся именно WordPress. Вот я прям сейчас буду подключать блог к системе git и описывать все необходимые действия.

По-хорошему, надо бы начать с описания, что же такое git. Подробно расписывать не буду, так как теории в интернете и так достаточно, кто не знает, полагаю, найдет информацию без проблем. А тому, кто попадет на эту статью из поисковика, скорей всего, нужны уже практические знания и примеры как настроить git для WordPress сайта. Но для подписчиков блога, чтобы у вас не создалось впечатления, что предлагается настраивать “кота в мешке”, все же, напишу несколько абзацев для общего представления.

Итак, git – система контроля версий. Позволяет хранить все файлы вашего проекта в централизованном хранилище. Вы сможете “развернуть” ваш сайт на любом компьютере, сервере и т.д., к которым у вас будет доступ. Т.е., вы сможете вносить изменения в проект на локальном компьютере (или нескольких компьютерах, расположенных в разных местах – на работе, дома и т.д.). Все эти правки будут попадать в центральное хранилище и у вас всегда будет доступ к актуальному состоянию сайта.

Помимо удобств центрального хранилища, у вас будет возможность делать “откаты” проекта до более раннего состояния. Например, вы внесли изменения в проект на локальном компьютере, протестировали – все ок. Подтянули эти новшества на хостинг (рабочую версию) и вдруг обнаружили какую-то ошибку. Тогда можно будет произвести “откат” проекта до предыдущего состояния для быстрого восстановления работоспособности сайта.

Еще одно удобство – вы сможете вести разработку (настройку) в нескольких разных ветках. Что это даст? Вот у меня, как раз, на днях спрашивали, как обезопасить свой сайт от “диверсий” фрилансеров. Т.е. бывают ситуации, когда человек не доверяет фрилансеру и боится отдавать ему всяческие пароли и беспокоится о том, чтобы в сайт не был внедрен какой-то вредоносный код, то в этом случае использование git – отличное решение.

Вам нужно только дать доступ на клонирование проекта. Фрилансер развернет все у себя на локальном компьютере. В отдельной ветке сделает все необходимые изменения и зальёт свою ветку в центральное хранилище вашего проекта. Вы сможете проверить работоспособность и увидеть в какие файлы вносились изменения и конкретно, что было добавлено и что было удалено или изменено. После того, как убедитесь что все работает и нет вредоносного кода – сольёте эту ветку с основной веткой проекта.

Еще ветвления можно использовать, когда у вас идет какая-то длительная работа, требующая несколько дней. Вы сможете выполнять разработку в отдельной ветке. И слить с основной веткой, только после того, как задача будет выполнена и протестирована.

Вообщем, давайте, ближе к делу, мы поняли, что git классная штука и срочно нужно применить и настроить его для своего блога. Приступим!

 

1. Убедимся, что у хостинг-провайдера установлен git.

Естественно, чтобы работать с git, нужно чтобы на сервере хостинг-провайдера был установлен git.

Чтобы проверить установлен ли git, нужно в консоли сервера хостинга выполнить одноименную команду git

В консоль можно зайти с помощью программы PuTTy (как с ней работать я еще не писал).

А можно, с помощью, уже знакомой нам WinSCP. Команды – Открыть терминал (ctrl+T).

Введите команду: git и нажмите кнопку “Выполнить”.

Если у вас после этого выпала “простыня” со справочной информацией о командах git как на скриншоте ниже, значит все ок – git на сервере установлен.

 

выполнение команд через терминал WinSCP

 

Если же вам выдало, что команда не известна, то напишите в поддержку хостинга, чтобы они установили git. Если же вдруг случится так, что вам откажут, то срочно меняйте хостера! Мой блог все еще на хостинге beget.ru, нареканий пока нет. Так что рекомендую!

 

2. Выбираем центральное хранилище и создаем репозиторий.

После того, как мы убедились, что сервер поддерживает работу с git, нам нужно определиться с центральным хранилищем, с которым мы будем работать.

Наиболее популярные, известные мне – это bitbucket.com и github.com. Буду рассказывать на примере bitbucket.com. Вам нужно создать аккаунт и залогиниться. Полагаю, с этим проблем не возникнет.

Теперь, когда вы авторизовались в bitbucket, создадим репозиторий (хранилище) для нашего проекта. Кликаем по ссылке “Create” вверху в меню.

 

создание репозитория в bitbucket

 

 

Далее

1. Заполняем название нашему репозиторию.

2. Выбираем язык PHP.

3. Жмем Create repository.

создание репозитория в bitbucket

 

Репозиторий создан.

 

3. Заливаем проект в репозиторий.

Теперь возвращаемся в консоль на сервер хостинга, где лежит актуальная версия сайта.

Нам нужно перейти в корень сайта. Вы можете это сделать в консоли с помощью команды cd (change directory), либо сначала перейти в корень в WinSCP, а потом вызвать терминал (ctrl+T) и таким образом корень сайта будет текущей директорией.

Создаем пустой git-репозиторий на сервере. Выполняем команду:

Добавляем все файлы проекта в репозиторий:

Внимание: файл .htaccess не попал под действие *.  Пришлось добавлять его отдельной командой с флагом –f (force).

Теперь описываю возникшую проблему в моем частном случае, возможно, кому-то пригодится. При попытке выполнить команду git add * получил ошибку.

fatal: Not a git repository: wp-content/plugins/crayon-syntax-highlighter/langs/vbnet/../../.git/modules/langs/vbnet

Дело в том, что я использую плагин crayon syntax highlighter и вот в указанной папке

/wordpress-life.ru/public_html/wp-content/plugins/crayon-syntax-highlighter/langs/vbnet

нахожу файл .git.

Скорей всего, автор плагина тоже использовал git и вот возник конфликт. Удаляю файл .git.

Вновь пытаюсь выполнить git add *. Опять ошибка.

fatal: Not a git repository: wp-content/plugins/crayon-syntax-highlighter/js/jquery-colorpicker/../../.git/modules/js/jquery-colorpicker

Уже  в другой папке

/wordpress-life.ru/public_html/wp-content/plugins/crayon-syntax-highlighter/js/jquery-colorpicker/

нахожу два файла: .git и .gitignore. Удаляю их.

После этого ошибок больше не возникает. Все файлы успешно добавлены в наш репозиторий на сервере хостинг-провайдера.

Выполняем commit изменений.

Теперь нужно зафиксировать выполненные изменения. Делается это с помощью команды commit.

С помощью параметра –m передается комментарий к коммиту.

Но, git не желает выполнять эту команду и просит представиться.

Please tell me who you are.

Run

Видимо, его с детства приучили не общаться с незнакомцами.

Так что придется указать свой мейл и имя, с помощью предложенных команд.

После это коммит успешно выполняется.

Добавляем удаленный репозиторий.

Под добавление удаленного репозитория имеется в виду назначение короткого алиаса (псевдонима) нашему репозиторию.

Вот длинное название репозитория:

https://yershov_alexey@bitbucket.org/yershov_alexey/wordpress_life.git

Где, yershov_alexey – имя пользователя bitbucket; wordpress_life.git – файл репозитория.

Чтобы каждый раз не писать полное название репозитория при выполнении команд git, мы только что назначили ему классический алиас origin.

Вот сейчас, как раз, увидите как мы будем использовать это новое имя при отсылке изменений на сервер bitbucket.

Отсылаем изменения в центральное хранилище.

Git спросит пароль вашего пользователя bitbucket и после того, как вы введете пароль, все сделанные изменения будут отправлены в центральное хранилище.

 

4. Разворачиваем проект из репозитория на локалхост.

Итак, на данный момент, у нас уже есть весь наш проект в центральном хранилище bitbucket и налажена связь с сервером хостинга.

Теперь, естественно, хотелось бы развернуть проект на локальном компьютере. Тогда мы сможем делать необходимые изменения на локалхосте и  после проверки работоспособности отправлять доработки в центральный репозиторий и затем выливать их на хостинг, где находится рабочая версия сайта.

В первом пункте мы проверяли установлен ли git на хостинге. Теперь нам нужно установить git на локальном компьютере.

Скачайте инсталлятор git для Windows здесь http://msysgit.github.io/ и установите у себя на компьютере.

Теперь с помощью файлового менеджера или проводника зайдите в папку в которой расположены сайты у вас на локалхосте, т.е. в корень локалхоста. Раньше в качестве локального сервера я использовал Denwer, но сейчас перешел на OpenServer. Сайты у меня лежат в папке d:/OpenServer/domains.

Создаем папку для нашего проекта. Свою я назвал wp-life.

Теперь нужно в эту папку клонировать проект из центрального репозитория. В консоли Windows (cmd) переходим в созданную только что папку проекта (wp-life) и выполняем следующую команду:

Обратите внимание на точку в конце команды. Она указывает на то, что клонирование будет происходить в текущую директорию.

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

Если все прошло успешно, то файлы проекта уже у вас на локальном компьютере.

Осталось произвести экспорт-импорт базы данных. Полагаю, тут у вас не должно возникнуть проблем. Наверняка, уже делали это ни один раз. Подробно описывать не буду. Сошлюсь на перенос информации из базы данных. Там я, правда, описывал обратный процесс – перенос сайта и БД с локального компьютера на сервер хостера. Но, суть от этого не меняется. Единственный нюанс, что параметры url в данном случае лучше изменять не через админку, а непосредственно в таблице БД или дампе БД. Собственно, это будет удобней в любом из случаев.

Коротко, по пунктам.

1. Делаете экспорт из БД (базы данных), расположенной на сервере. Скорей всего, через phpMyAdmin на вашем хостинге.

2. На локальном компьютере создаете БД, если еще не создали. Желательно с таким же именем, как и на сервере, чтобы не изменять ничего в конфигурационных файлах. Так же имя пользователя и пароль доступа к локальной базе данных лучше иметь такие же как и на сервере. Либо, можно добавить нового пользователя в локальной БД, но это я опишу в отдельной статье.

3. Выполняете импорт в локальную БД.

4. После импорта в локальной БД в таблице  wp_options нужно изменить значения параметров siteurl и home.

У меня в этих параметрах было значение http://wordpress-life.ru, на локалхосте заменил на http://wp-life.

Готово! У меня все заработало!

Как с этим всем обращаться буду писать в следующих статьях. А пока публикую эту “простыню” (похоже, первая статья на блоге более 10тыс. символов). Может кому-то да пригодится. Бывает так, что ты не применяешь в целом то, что написано в статье, но узнаешь какую-то одну нужную тебе вещь.

Вообщем, я доволен! Во-первых, что теперь буду вести работы по блогу через git. Во-вторых, что изложил процесс подключения git к WordPress в этой статье. Если где-то что-то упустил или непонятно объяснил – спрашивайте.

Всем творческого развития!

До новых публикаций!

Понравилась статья? Не забудьте поделиться с друзьями и коллегами:

Вы можете пропустить чтение записи и оставить комментарий. Размещение ссылок запрещено.

15 комментариев к записи “Подключаем Git к проекту WordPress”

  1. Виктория

    Спасибо, то что нужно. Весь инет перерыла, а нашла у Вас!

  2. Виктория

    А как происходит обновление плагинов? Если сделать обновление на локальной копии, то потом надо будет и базу данных переносить?

    • Алексей Ершов

      Да, получается так. С установкой новых плагинов проще. Нужно установить локально, сделать коммит и залить на сервер. И на сервере останется только активировать новые плагины. А вот с обновлением существующих плагинов получается нужно и изменения в базе переносить. Лучше тогда обновлять на сервере и переносить на локаль вместе с более актуальной базой, но опять же сам процесс обновления сначала желательно протестить на локали… =)

    • Алексей Ершов

      Виктория, получается
      1. Если проект в разработке, то делаете все на локали и потом заливаете на сервер и переносите базу.
      2. На рабочем проекте обновление плагинов удобней делать на сервере и потом заливать результаты в хранилище, тянуть изменения на локальную версию и обновлять базу на локали.

  3. Виктория

    Спасибо :)

  4. Alex

    А что будет, если зашли в админку сайта, добавили новую страницу, залили новые картинки..
    и потом git status!
    Что будет и как это фиксить, если контент регулярно добавляется!?

    Я надеюсь поняли о чем идет речь.

    • Алексей Ершов

      1 вариант. Коммитить и пушить с сервера все изменения.
      2 вариант. Не заливать (игнорить) наполняемый контент в гит. В этом случае гит будет служить хранилищем файлов только для групповой (одиночной) разработки, но при этом не будет хранить весь сайт полностью со всем содержимым. Т.е. вопросом полного бэкапа нужно будет заниматься отдельно. Тем более, БД все-равно нужно бэкапить отдельно.

      • Александр

        Алексей, объясните пожалуйста почему БД нужно бекапить отдельно? У меня на сервере она отдельным файлом лежит с расширением SQL. Можно ли это файл так же заливать на локальную копию через GIT?

        • Алексей Ершов

          Да, если какой-то плагин или инструмент хостинга делает бэкап БД и сохраняет файл на сервере, то можно этот файл добавить в проект git и соответственно он будет подтягиваться командой pull наряду с другими файлами проекта.
          Единственное, в этом случае, чтобы залить какие-то изменения на сервер после очередного бэкапа, придется сперва на сервере сделать commit и push и только потом pull, поскольку в файле дампа БД будут изменения, не залитые в репозитарий.

  5. Андрей

    А разве нельзя сделать связку хостинг – локальный комп?
    Зачем нужно промежуточное звено bitbucket.org ?

    • Алексей Ершов

      Промежуточное звено нужно, чтобы вы (или кто-то другой с вашего разрешения) могли получить клон (полную копию проекта) на компьютер. Поработать, внести необходимые изменения, протестировать и залить на хостинг (через центральное хранилище bitbucket или подобное) уже проверенный, рабочий вариант. Над проектом, ведь, могут работать десятки человек. И благодаря промежуточному звену каждый из них будет иметь актуальную версию проекта со всеми изменениями, которые сделали коллеги.

  6. Роман

    Хорошая статья, спасибо. Только начал осваивать Git, благодаря вам получилось все подключить, т.к. других мануалов не нашел в интернете :) Жаль только, что мало статей на сайте на эту тему :(

  7. Site

    Хорошая статья, спасибо. Только начал осваивать Git, благодаря вам получилось все подключить, т.к. других мануалов не нашел в интернете :) Жаль только, что мало статей на сайте на эту тему :(

  8. Александра

    Я работаю с сайтами на битриксе, но все равно пригодилось, спасибо!
    1) Пока пропустила пункт 4. Можно ли обойтись без него? (Например, для своего личного сайта я – единственный разработчик, и до этого работала напрямую на сайте – я могу создавать ветки прямо там? Не очень охота тащить на семейный компьютер вебсервер).
    2) Кстати, чем OpenServer лучше Денвера? До этого я пользовалась только денвером.

    • Алексей Ершов

      1. Да, можно вносить правки напрямую на сервере, потом коммитить и делать push в репозитарий. Но, если сайт с большой посещаемостью, то, правки на сервере, как понимаете, – это не очень хорошо.
      2. Лучше просто установить и посмотреть своими глазами. Там куча всяких вспомогательных программ идет в пакете, удобные настройки и т.п.

Оставить комментарий

Для размещения кода в комментарии используйте теги <pre> </pre>, например:


Подписаться, не комментируя