Advertisement
  1. Code
  2. Plugins

Публикация плагинов WordPress с помощью Git

by
Difficulty:AdvancedLength:LongLanguages:

Russian (Pусский) translation by Svetlana (you can also view the original English article)

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


Что такое Git?

Git и SVN являются примерами систем контроля версий. В хранилище WordPress используется последнее (если у вас есть плагин, размещенный на WordPress, вы будете знакомы с «регистрацией» для внесения изменений в это хранилище). Они оба позволяют вам отслеживать изменения в вашем коде, но между ними есть большие различия в том, как они это делают.

SVN опирается на единое «центральное хранилище» кода (в нашем контексте: хранилище плагинов WordPress). Каждый раз, когда вы хотите отредактировать свой плагин, вам нужно сделать локальную копию, внести изменения, а затем «зарегистрировать» эти изменения в хранилище WordPress.

Git - децентрализованная система контроля версий. Вместо того, чтобы иметь только локальную копию вашего плагина - у вас есть полный клон вашего плагина, со всеми его изменениями. Хранилище теперь существует отдельно на вашем компьютере. Вы можете фиксировать и отслеживать изменения, отменять изменения или «разветвлять» свой плагин в разных направлениях на локальном компьютере. Только после того, как вы обновите свой плагин, вы можете отправить свои изменения в своё хранилище WordPress, чтобы сделать их общедоступными.

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


Каковы преимущества использования Git над SVN?

Существует множество аргументов за и против использования Git поверх SVN (а также децентрализованных систем контроля версий в целом). Многие из них проистекают из принципиально разных способов отслеживания изменений в Git и SVN. Отличный, глубокий анализ Git и SVN можно найти в статье CodeForest Git vs SVN, но для разработчика WordPress:

  • Автономный доступ - вы можете создавать и отслеживать коммиты в своем личном «хранилище разработки». Только когда вы хотите сделать ваши изменения общедоступными, вам нужен доступ к хранилищу WordPress.
  • Как только вы изучите его, Git станет намного проще в использовании - эта статья проведет вас через основной рабочий процесс, который вам понадобится для внесения изменений и обновления их в хранилище. Внизу я ссылаюсь на некоторые ресурсы, которые предоставляют более подробную информацию об использовании Git.
  • GitHub - Посмотрим правде в глаза, именно так большинство из нас слышали о Git. Его способность поощрять «Социальное кодирование» стала возможной благодаря децентрализованной природе Git. Вы можете сохранить копию своего плагина на GitHub, поощряя сообщество участвовать и вносить улучшения или расширения, которые вы затем можете включить. Вообще говоря, это хорошая идея - показать ваш плагин другим разработчикам.
  • Простое «ветвление» вашего плагина - вы можете создавать «экспериментальные» ветки в своей локальной копии для тестирования возможных новых функций, а затем, если они сработают, объединить их обратно, когда придет время опубликовать следующий выпуск вашего плагина. ,

Один из недостатков использования Git - заставить его хорошо играть с хранилищем SVN. Это на самом деле не так сложно благодаря git svn, и эта статья поможет вам в этом.


Шаг 1 скачать Git

Если вы еще этого не сделали, вам нужно установить Git. Как установить Git довольно хорошо описано в книге сообщества Git и книге Pro Git (оба отличных ресурса, если вы новичок в Git). Как установить Git, будет зависеть от вашей операционной системы, а также от того, какие программы GUI вам доступны. В этом уроке я сделаю все через командную строку - и я призываю вас сделать то же самое. В конце статьи я предложу некоторые программы с графическим интерфейсом, которые вы можете использовать, но обычно я использую их только для визуализации ветвей хранилища.


Шаг 2 Клонируйте WordPress-плагин для вашего плагина

Как уже упоминалось ранее, с Git вы не «извлекаете» копию своего плагина - вы клонируете хранилище, полный истории внесенных изменений, а также всех его ветвей и тегов. Шаг 1 - это клонирование хранилища WordPress вашего плагина. В качестве примера я опубликую плагин 'Post Type Archives Link' на основе предыдущего урока. Поэтому (как только вы будете приняты в хранилище WordPress), откройте интерфейс командной строки и перейдите туда, где вы хотите хранить локальную версию вашего плагина. Я собираюсь поместить его в папку под названием «Плагины». Оказавшись там, мы хотим сказать Git, где найти наш плагин. На момент написания этой статьи в хранилище WordPress размещалось около 20 000 плагинов и более 500 000 ревизий. Мы не хотим ждать, пока Git проследит за каждым из них, чтобы найти наш плагин. Итак, во-первых, мы находим, с какой ревизии начинается наш плагин (мы хотим, чтобы это была вся история). Для этого мы получаем первый журнал вашего плагина (когда он был первоначально добавлен в хранилище):

Некоторое время он будет думать, а затем вы должны увидеть что-то вроде этого:

Первый номер, «520657» для моего плагина, является первой ревизией. Мы будем использовать его в следующей команде, которая говорит Git клонировать историю нашего плагина. Замените XXXXXX на номер ревизии.

'-S' указывает Git ожидать стандартную (Tag, Trunk, Branches) компоновку хранилища SVN. «--No-minimal-url» останавливает его поиск за пределами вашей папки плагина. Убедитесь, что это не пропало. Если вы пропустите это, вы можете скопировать всё хранилище плагинов WordPress. -rXXXXXX сообщает Git, какую ревизию искать. Если вы пропустите это, Git будет выполнять поиск по всей истории хранилища. Это более 500 000 ревизий. Я оставил это один раз, и это заняло около двух часов. С этим, это займет всего несколько минут.

Как только это будет сделано, вы должны обнаружить, что он создал папку под названием «ваше имя подключаемого модуля» внутри папки «Подключаемые модули». Давайте рассмотрим немного. Перейдите в папку «your-plug-in-name» и выполните команду, чтобы увидеть, какие существуют «ветви»:

Это будет список всех филиалов, локальных и удаленных. Единственная локальная ветвь должна быть Master (звездочка обозначает, что это та ветка, в которой вы находитесь). Другие ветви - это «ствол» и, если есть, ветвь для каждого тега (SVN рассматривает теги как ветви, но Git немного умнее этого).

Перейдя в вашу «локальную папку», «plugins / your-plugin-name», вы должны увидеть файлы вашего плагина (если они были). Прежде чем создавать или редактировать какие-либо файлы, мы собираемся создать отдельную ветку для работы.

Обновление: команды выше были обновлены из-за проблемы, отмеченной в комментариях ниже Neerav и Джоном Экманом. Код выше теперь отражает рекомендацию Стивена Харриса.


Шаг 3 (необязательно) нажмите на GitHub

Одним из преимуществ использования Git является то, что вы можете легко поддерживать версию своего плагина на GitHub. Это делает ваш плагин более доступным для других разработчиков, которые могут предлагать улучшения или даже вносить свои собственные модификации, которые вы можете добавить в своё собственное хранилище . Если вы уже настроены с GitHub, вы можете добавить свой плагин в свою учетную запись. Для этого сначала создайте себе новое хранилище в своей учетной записи GitHub, а затем добавьте его в качестве удаленной ветви в локальное хранилище:

'your-user-name' относится к вашему имени пользователя GitHub, и 'your-repo-name' относится к имени хранилище, который вы создали на GitHub. Затем вы просто нажимаете своё локальное хранилище:


Шаг 4 Редактирование плагина: Обзор рабочего процесса

Мы создадим новую ветку «Работа». Именно внутри этой ветки мы будем изменять наш плагин, вносить изменения и добавлять функции и т. д. Это означает, что наша ветка «Мастер» остается в своем первоначальном состоянии. Это позволяет нам вернуться в ветку Master и снова разветвляться. В частности, предположим, что в вашем плагине обнаружена серьезная ошибка, когда вы работаете над некоторыми новыми функциями в ветке «работа». Вы можете переключиться обратно в свою «основную» ветку (которая не включает в себя какие-либо функции, над которыми вы сейчас работаете), зафиксировать исправление для ошибки и затем отправить это в хранилище WordPress. Затем вы можете вернуться в свою рабочую ветку и продолжить с того места, где остановились. (Примечание: Git не создает копии ваших файлов - в вашей локальной папке всегда будет только один набор файлов. То, что эти файлы содержат, будет зависеть от того, в какой ветке вы находитесь.)

На самом деле, это хорошая идея - создавать ветку для каждой новой функции, которую вы добавляете в свой плагин. Когда вы закончите, вы просто объедините их обратно в основную ветку. Если это вызывает какие-либо «конфликты», вас попросят разрешить их вручную.

Сначала создайте ветку под названием «работа»:

Затем «проверить» филиал «работа» (перейти):

Сообщение сообщит вам, что вы переключились на ветку 'работа'. Теперь используйте ваш любимый текстовый редактор, чтобы открыть файлы вашего плагина в локальной папке (или создайте их, если их еще нет). После того как вы сделали несколько, вы можете посмотреть, какие файлы вы изменили. Вы делаете это с помощью простой команды:

Это будет список изменений отслеживаемых и неотслеживаемых файлов. Могут быть файлы, которые вы не хотите, чтобы Git беспокоил отслеживание (например, временные файлы), но если вы добавили какие-либо новые файлы в папку, вам нужно будет сказать Git отслеживать их. Вы можете сделать это с помощью команды:

Я создал два файла 'post-type-archive-links.php' и 'metabox.js' в своей локальной папке, поэтому я добавил их, чтобы Git отслеживал их. Вы должны убедиться, что вы отслеживаете свой файл readme.

Вы также можете просмотреть изменения с момента последней передачи данных (именно здесь программа с графическим интерфейсом становится очень удобной)

Как только вы захотите зафиксировать изменения в вашем локальном хранилище:

предоставление (подробного) сообщения об изменениях, содержащихся в передаче данных.

В процессе внесения изменений вы можете (и должны) совершать передачу данных как можно чаще, но логичным способом, предпочтительно с одной передачей данных для каждой «вещи», которую вы делаете. Вы также должны убедиться, что в ваших передачах данных нет явных ошибок. «Отмена» передачи данных происходит быстро и безболезненно: вы делаете это, выполняя другой передачей данных, который отменяет предыдущий:

(Вам будет предложено сообщение с описанием этой передачи данных.)


Шаг 5 Передача в хранилище WordPress

Предположим, вы сейчас находитесь в положении, когда хотите перенести все свои изменения в хранилище SVN. Прежде чем сделать это, нам нужно кое-что обдумать. Git призывает вас часто совершать передачи данных, и это хорошая практика ... для развития. Тем не менее, ваш плагин WordPress хранилище предназначен для распространения. Это не нуждается в каждой передаче данных. На самом деле, он тоже не хочет этого, как предупреждает Отто (основной вкладчик WordPress):

«Если я поймаю вас на этом [подталкивая каждую передачу данных отдельно], то я не позволю вам использовать WordPress.org. SVN нужна только ваша окончательная рабочая версия, а не вся история сотен изменений, которые вы сделали с помощью Git. Свести ваши изменения в одну передачу данных. "

Чтобы избежать этого, когда мы готовы перейти в хранилище WordPress, мы объединяем все передачи данных в одну передачу. Есть несколько способов сделать это. Мы должны объединить (и одновременно нажать) наши изменения от нашей работы филиала в нашей ветки master. Тогда все наши изменения появляются как один передача данных в ветке master. Затем мы удаляем рабочую ветвь и помещаем основную ветвь в ствол SVN нашего плагина.

Во-первых мы хотим, чтобы вернуться в мастер филиал:

Затем нажмите и слияние рабочей ветки превращается в лучшие:

Если в основную ветку были внесены изменения, возможно, при объединении возникли конфликты. Вам будет предложено вручную разрешить эти конфликты до завершения слияния. После объединения зафиксируйте изменения (этот передача будет содержать все передачи данных из нашей рабочей ветки):

Наконец, мы удаляем рабочую ветку

Если у вас есть несколько веток, которые вы хотите объединить, то вы можете сделать это для каждой из них. Существуют альтернативные методы, которые я не расскажу, для выравнивания вашей истории (например, интерактивное перебазирование).

На этом этапе вы можете, если хотите, добавить последние изменения в свою учетную запись GitHub:

Чтобы перейти к хранилищу WordPress, мы сначала должны убедиться, что наше локальное хранилище обновлено:

Затем Git отправит вам ваше хранилище Subversion и объединит все изменения с только что внесенными нами изменениями. Обычно не должно быть никаких изменений в хранилище WordPress, поэтому вы должны увидеть сообщение: Текущая основная ветка обновлена.

Теперь мы можем выдвинуть наши изменения хранилища WordPress

Затем Git может запросить у вас учетные данные WordPress.org. После внесения ваши изменения будут зафиксированы в хранилище WordPress. Вскоре вы должны получить электронное письмо из хранилища WordPress, информирующее вас о передаче данных.


Шаг 6 Маркировка нового выпуска

В настоящее время те изменения будут сидеть в стволе. Что, если мы хотим пометить новый выпуск нашего программного расширения? Создавая следующую версию для Вашего программного расширения Вы должны были обновить файл ReadMe, так, чтобы стабильный признак указал на Вашу новую версию (скажите '2.0'). Вы должны были также обновить информацию о заголовке своего программного расширения в вашем your-plug-in-name.php name.php файле. Если Вы забыли делать это, просто пробегите вышеупомянутую процедуру, внеся те изменения.

Как только Ваш 'ствол' полностью современен (включая последнюю информацию о версии), мы просто тогда должны создать новый признак в хранилище WordPress:

Это копирует все в Вашем стволе в признаки/2.0 (чего Вы обычно достигаете в SVN с svn признаками/2.0 ствола CP).

Если Вы хотели пометить выпуск в своем местном хранилище:


Шаг 7, (Дополнительно) помечающий новый выпуск на GitHub

Подобно тому, что мы сделали с хранилищем WordPress, убедитесь, что наши хранилища согласны, а затем отправьте наши изменения и теги:


Полезные ресурсы для команд Git

Наконец, есть пара «шпаргалок» Git, которые могут пригодиться: здесь и здесь.


GUI Git программы

Windows

  • TortoiseGit (популярная программа, которая хорошо интегрируется с Windows Explorer)
  • msysgit

Mac

Linux / плюс платформа

  • GitG (это то, что я использую)
  • QGit
  • Git Cola (плюс платформа)
Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.