Если у вас есть плагин, размещенный в репозитории 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 проследит за каждым из них, чтобы найти наш плагин. Итак, во-первых, мы находим, с какой ревизии начинается наш плагин (мы хотим, чтобы это была вся история). Для этого мы получаем первый журнал вашего плагина (когда он был первоначально добавлен в хранилище):
|
1
|
svn log -r 1:HEAD —limit 1 http://plugins.svn.wordpress.org/your-plug-in-name
|
Некоторое время он будет думать, а затем вы должны увидеть что-то вроде этого:
|
1
|
r520657 |
|
Первый номер, «520657» для моего плагина, является первой ревизией. Мы будем использовать его в следующей команде, которая говорит Git клонировать историю нашего плагина. Замените XXXXXX на номер ревизии.
|
1
2
3
4
|
git svn clone -s -rXXXXXX —no-minimize-url http://plugins.svn.wordpress.org/your-plug-in-name
cd your-plugin-name
git svn fetch
git svn rebase
|
‘ -s ‘ указывает Git ожидать стандартную (Tag, Trunk, Branches) компоновку репозитория SVN. « --no-minimize-url » останавливает его поиск за пределами вашей папки плагина. Убедитесь, что это не пропало . Если вы пропустите это, вы можете скопировать весь репозиторий плагинов WordPress. -rXXXXXX сообщает Git, какую ревизию искать. Если вы пропустите это, Git будет выполнять поиск по всей истории хранилища. Это более 500 000 ревизий. Я оставил это один раз, и это заняло около двух часов. С этим, это займет всего несколько минут.
Как только это будет сделано, вы должны обнаружить, что он создал папку под названием « ваше имя плагина » внутри вашей папки «Плагины». Давайте рассмотрим немного. Перейдите в папку « your-plug-in-name » и выполните команду, чтобы увидеть, какие существуют «ветви»:
|
1
|
git branch -a
|
Это будет список всех филиалов, локальных и удаленных. Единственная локальная ветвь должна быть Master (звездочка обозначает, что это та ветка, в которой вы находитесь). Другие ветви — это «ствол» и, если есть, ветвь для каждого тега (SVN рассматривает теги как ветви, но Git немного умнее этого).
Перейдя в вашу «локальную папку», « plugins / your-plugin-name », вы должны увидеть файлы ваших плагинов (если они были). Прежде чем создавать или редактировать какие-либо файлы, мы собираемся создать отдельную ветку для работы.
Обновление: команды выше были обновлены из-за проблемы, отмеченной в комментариях ниже Нерава и Джона Экмана. Код выше теперь отражает рекомендацию Стивена Харриса .
Шаг 3 (Необязательно) Нажмите для GitHub
Одним из преимуществ использования Git является то, что вы можете легко поддерживать версию своего плагина на GitHub. Это делает ваш плагин более доступным для других разработчиков, которые могут предлагать улучшения или даже вносить свои собственные изменения, которые вы можете добавить в свой собственный репозиторий. Если вы уже настроили GitHub, возможно, вы захотите добавить свой плагин в свою учетную запись. Для этого сначала создайте себе новый репозиторий в своей учетной записи GitHub, а затем добавьте его в качестве удаленной ветви в локальный репозиторий:
|
1
|
git remote add origin [email protected]:<your-user-name>/<your-repo-name>.git
|
‘ your-user-name ‘ относится к вашему имени пользователя GitHub, а ‘ your-repo-name ‘ относится к имени репозитория, который вы создали на GitHub. Затем вы просто нажимаете свой локальный репозиторий:
|
1
|
git push origin master
|
Шаг 4 Редактирование вашего плагина: описание рабочего процесса
Мы создадим новую ветку «Работа». Внутри этой ветки мы будем изменять наш плагин, вносить изменения и добавлять функции и т. Д. Это означает, что наша ветка «Мастер» остается в своем первоначальном состоянии. Это позволяет нам вернуться в ветку Master и снова разветвляться. В частности, предположим, что в вашем плагине обнаружена серьезная ошибка, когда вы работаете над некоторыми новыми функциями в ветке «работа». Вы можете переключиться обратно в свою «основную» ветку (которая не включает в себя какие-либо функции, над которыми вы сейчас работаете), зафиксировать исправление ошибки и затем отправить его в репозиторий WordPress. Затем вы можете вернуться в свою рабочую ветку и продолжить с того места, где остановились. ( Примечание: Git не создает копии ваших файлов — в вашей локальной папке всегда будет только один набор файлов. То, что эти файлы содержат, будет зависеть от того, в какой ветке вы находитесь.)
На самом деле, это хорошая идея — создавать ветку для каждой новой функции, которую вы добавляете в свой плагин. Когда вы закончите, вы просто объедините их обратно в основную ветку. Если это вызывает какие-либо «конфликты», вас попросят разрешить их вручную.
Сначала создайте ветку под названием «работа»:
|
1
|
git branch work
|
Затем «проверить» (перейти к) филиал «работа»:
|
1
|
git checkout work
|
В сообщении будет указано, что вы переключились на ветку «Работа». Теперь используйте ваш любимый текстовый редактор, чтобы открыть файлы вашего плагина в локальной папке (или создайте их, если их еще нет). После того как вы сделали несколько, вы можете посмотреть, какие файлы вы изменили. Вы делаете это с помощью простой команды:
|
1
|
git status
|
Это будет список изменений отслеживаемых и неотслеживаемых файлов. Могут быть файлы, которые вы не хотите, чтобы Git беспокоил отслеживание (например, временные файлы), но если вы добавили какие-либо новые файлы в папку, вам нужно будет сказать Git отслеживать их. Вы можете сделать это с помощью команды:
|
1
|
git add <file-name>
|
Я создал два файла ‘ post-type-archive-links.php ‘ и ‘ metabox.js ‘ в своей локальной папке, поэтому я добавил их, чтобы Git отслеживал их. Вы должны убедиться, что вы отслеживаете свой файл readme .
Вы также можете просмотреть изменения с момента вашего последнего коммита (именно здесь программа с графическим интерфейсом становится очень удобной)
|
1
|
git diff
|
Как только вы захотите зафиксировать изменения в вашем локальном репозитории:
|
1
|
git commit -a -m «Did abc to xyz»
|
предоставление ( подробного ) сообщения об изменениях, содержащихся в коммите.
В процессе внесения изменений вы можете (и должны) совершать коммит как можно чаще, но логичным способом, предпочтительно с одним коммитом для каждой «вещи», которую вы делаете. Вы также должны убедиться, что в ваших коммитах нет явных ошибок. «Отмена» коммита происходит быстро и безболезненно: вы делаете это, выполняя другой коммит, который отменяет предыдущий:
|
1
|
git revert HEAD
|
(Вам будет предложено сообщение для описания этого коммита.)
Шаг 5 Передача в репозиторий WordPress
Предположим, вы сейчас находитесь в положении, когда хотите перенести все свои изменения в репозиторий SVN. Прежде чем сделать это, нам нужно кое-что обдумать. Git призывает вас часто совершать коммиты, и это хорошая практика … для развития . Тем не менее, ваш плагин WordPress репозиторий предназначен для распространения . Это не нуждается в каждом коммите. На самом деле, он тоже не хочет этого, как предупреждает Отто (основной вкладчик WordPress):
«Если я поймаю вас на этом [подталкивая каждый коммит отдельно], то я забаню вас на WordPress.org. SVN нужна только ваша окончательная рабочая версия, а не вся история сотен изменений, которые вы сделали с помощью Git. Свести ваши изменения в один коммит. «
Чтобы избежать этого, когда мы готовы перейти в репозиторий WordPress, мы объединяем все коммиты в один коммит. Есть несколько способов сделать это. Мы объединяем (и одновременно подавляем) наши изменения из нашей рабочей ветви в нашу основную. Тогда все наши изменения появляются как один коммит в ветке master. Затем мы удаляем рабочую ветвь и помещаем основную ветвь в ствол SVN нашего плагина.
Сначала мы хотим вернуться в ветку Master:
|
1
|
git checkout master
|
Затем сквош и слияние рабочей ветки превращается в мастера:
|
1
|
git merge —squash work
|
Если в основную ветку были внесены изменения, возможно, при слиянии возникли конфликты. Вам будет предложено вручную разрешить эти конфликты до завершения слияния. После объединения зафиксируйте изменения (этот коммит будет содержать все коммиты из нашей рабочей ветки):
|
1
|
git commit -a -m «Made changes a,b,c,d»
|
Наконец, мы удаляем рабочую ветку
|
1
|
git branch -D work
|
Если у вас есть несколько веток, которые вы хотите объединить, то вы можете сделать это для каждой из них. Существуют альтернативные методы, которые я не расскажу, для выравнивания вашей истории (например, интерактивный перебаз ).
На этом этапе вы можете, если хотите, добавить последние изменения в свою учетную запись GitHub:
|
1
|
git push -u origin master
|
Чтобы перейти в репозиторий WordPress, мы сначала должны убедиться, что наш локальный репозиторий обновлен:
|
1
|
git svn rebase
|
Затем Git отправит вам ваш репозиторий subversion и объединит все изменения с только что внесенными нами изменениями. Обычно не должно быть никаких изменений в репозитории WordPress, поэтому вы должны увидеть сообщение: Текущий мастер ветки обновлен .
Теперь мы можем перенести наши изменения в репозиторий WordPress.
|
1
|
git svn dcommit
|
Затем Git может запросить у вас учетные данные WordPress.org. После внесения ваши изменения будут зафиксированы в репозитории WordPress. Вскоре вы получите электронное письмо из репозитория WordPress, информирующее вас о коммитах.
Шаг 6 Пометка новой версии
В настоящее время эти изменения будут сидеть в багажнике. Что если мы хотим пометить новую версию нашего плагина? При создании следующей версии для вашего плагина вы должны были обновить файл ReadMe, чтобы стабильный тег указывал на вашу новую версию (скажем, «2.0»). Вы также должны были обновить информацию заголовка вашего плагина в файле your-plug-in-name.php . Если вы забыли это сделать, просто выполните описанную выше процедуру, внеся эти изменения.
Когда ваш «ствол» полностью обновлен (включая информацию о последней версии), нам просто нужно создать новый тег в репозитории WordPress:
|
1
|
git svn tag «2.0»
|
Это копирует все в вашем транке в tags / 2.0 (что вы обычно добиваетесь в SVN с помощью svn cp trunk tags/2.0 ).
Если вы хотите пометить релиз в вашем локальном репозитории:
|
1
|
git tag -a 2.0 -m»Tagging 2.0″
|
Шаг 7 (Необязательно) Пометка новой версии на GitHub
Аналогично тому, что мы сделали с репозиторием WordPress, убедитесь, что наши репозитории согласны, а затем отправьте наши изменения и теги:
|
1
2
3
|
git pull —rebase origin master
git push origin master
git push origin —tags
|
Полезные ресурсы для команд Git
- Git Reference (Имеет хороший раздел «Как думать, как Git»)
- Git Сообщество книга
- Pro Git book
- Git Ready (меньше руководства, больше коллекция фрагментов)
- Курс SVN to Git (полезно, если вы некоторое время использовали SVN)
- Git Magic (дружеское введение в Git)
Наконец, есть пара «шпаргалок» Git, которые могут пригодиться: здесь и здесь .
GUI Git Программы
Windows
- TortoiseGit (популярная программа, которая хорошо интегрируется с Windows Explorer)
- msysgit
макинтош
- Git Tower
- GitHub для Mac (от тех, кто принес вам GitHub)