Menerbitkan pemalam WordPress menggunakan Git

Jika anda mempunyai pemalam yang dihoskan pada repositori WordPress, anda pasti sudah biasa dengan SVN dan beberapa arahannya. Dalam tutorial ini, saya akan menunjukkan kepada anda cara menggunakan Git, sistem kawalan versi lain yang dipopularkan oleh GitHub, untuk menerbitkan dan mengekalkan pemalam anda.

---

Apakah itu Git?

Git dan SVN ialah kedua-dua contoh sistem kawalan versi. Repositori WordPress menggunakan yang terakhir (jika anda mempunyai pemalam yang dihoskan pada WordPress, anda akan biasa dengan "mendaftar masuk" untuk membuat perubahan pada repositori ini). Kedua-duanya membenarkan anda menjejaki perubahan pada kod anda, tetapi terdapat perbezaan besar dalam cara mereka melakukannya.

SVN bergantung pada satu "repositori pusat" kod (dalam konteks kami: repositori pemalam WordPress). Setiap kali anda ingin mengedit pemalam, anda perlu membuat salinan setempat, membuat perubahan anda, dan kemudian "mendaftar masuk" perubahan tersebut ke repositori WordPress.

Git ialah sistem kawalan versi terdesentralisasi. Bukan sahaja anda mempunyai salinan tempatan pemalam, anda juga mempunyai klon lengkap repositori pemalam, dengan semua perubahannya. Repositori kini wujud secara bebas pada komputer anda. Anda boleh melakukan dan menjejaki perubahan, mengembalikan perubahan atau "mencabangkan" pemalam ke arah yang berbeza pada mesin setempat anda. Hanya jika anda bersedia untuk mengemas kini pemalam anda akan menolak perubahan pada repositori WordPress untuk menjadikannya umum.

Dalam tutorial ini, saya mengandaikan anda sudah mempunyai pemalam yang dihoskan pada repositori pemalam WordPress, atau sekurang-kurangnya permintaan pengehosan anda telah diluluskan. Jika anda tidak pasti cara membuat pemalam anda dihoskan oleh WordPress, saya syorkan membaca artikel kami tentang cara menerbitkan ke repositori pemalam WordPress.

---

Apakah kelebihan menggunakan Git berbanding SVN?

Terdapat banyak hujah menyokong dan menentang penggunaan Git dan bukannya SVN (dan sistem kawalan versi terdesentralisasi secara umum). Kebanyakan perkara ini berpunca daripada cara perubahan jejak Git dan SVN yang pada asasnya berbeza. Artikel Git vs SVN CodeForest menyediakan analisis Git dan SVN yang hebat dan mendalam, tetapi untuk pembangun WordPress:

• Akses luar talian – Anda boleh membuat dan menjejaki komitmen pada "repositori pembangunan" peribadi anda sendiri. Akses kepada repositori WordPress hanya diperlukan jika anda ingin membuat perubahan anda kepada umum.
• Sebaik sahaja anda mempelajari Git, ia menjadi lebih mudah digunakan - artikel ini akan membimbing anda melalui aliran kerja asas yang diperlukan untuk membuat perubahan dan kemas kini dalam repositori anda. Saya telah memautkan kepada beberapa sumber di bahagian bawah yang memberikan butiran lanjut tentang menggunakan Git.
• GitHub - Mari kita hadapi, ini adalah bagaimana kebanyakan kita mendengar tentang Git. Sifat terdesentralisasi Git membolehkannya menggalakkan "pengekodan sosial." Anda boleh menyimpan salinan pemalam di GitHub, menggalakkan penyertaan komuniti dan penambahbaikan atau sambungan, yang kemudiannya boleh anda sertakan. Secara umum, adalah idea yang baik untuk mendedahkan pemalam anda kepada pembangun lain.
• Mudah "membuat" pemalam anda - Anda boleh membuat cawangan "percubaan" pada salinan setempat anda untuk menguji kemungkinan ciri baharu, dan kemudian, jika ia berfungsi, gabungkannya semula apabila versi pemalam seterusnya dikeluarkan.

Satu kelemahan menggunakan Git ialah menjadikannya berfungsi dengan baik dengan repositori SVN. Terima kasih git svn sebenarnya tidak begitu sukar dan artikel ini ada di sini untuk membimbing anda melaluinya.

---

Langkah 1Muat Turun Git

Jika anda belum memasang Git lagi, anda perlu memasangnya. Cara memasang Git diperincikan dalam Buku Komuniti Git dan Buku Pro Git (dua sumber Cemerlang jika anda baru menggunakan Git). Cara anda memasang Git bergantung pada sistem pengendalian anda dan program GUI yang tersedia untuk anda. Dalam tutorial ini, saya akan melakukan segala-galanya melalui baris arahan - saya menggalakkan anda untuk melakukan perkara yang sama. Pada penghujung artikel, saya akan mengesyorkan beberapa program GUI yang boleh anda gunakan, tetapi secara amnya, saya hanya menggunakannya untuk membantu menggambarkan cawangan repositori.

---

Langkah 2Klon repositori pengehosan WordPress pemalam

Seperti yang dinyatakan sebelum ini, dengan Git anda tidak perlu "menyemak" salinan pemalam - anda boleh mengklon repositori dan menyertakan sejarah perubahan yang anda buat, bersama dengan semua cawangan dan tegnya. Langkah 1 ialah mengklon repositori pengehosan WordPress pemalam. Sebagai contoh, saya akan menerbitkan pemalam "Pautan Arkib Jenis Pos" berdasarkan tutorial sebelumnya. Jadi (sebaik sahaja anda diterima masuk ke dalam repositori WordPress) buka antara muka baris arahan anda dan navigasi ke tempat anda ingin menyimpan versi tempatan pemalam anda. Saya akan meletakkannya dalam folder yang dipanggil "Plugins". Sebaik sahaja di sana, kami ingin memberitahu Git di mana untuk mencari pemalam kami. Sehingga penulisan ini, terdapat hampir 20,000 pemalam yang dihoskan dalam repositori WordPress dengan lebih 500,000 semakan. Kami tidak mahu menunggu Git menyemak setiap satu untuk mencari pemalam kami. Jadi pertama, kami mencari versi permulaan pemalam (kami mahu ia menjadi keseluruhan sejarah). Untuk melakukan ini, kami mendapat log pertama pemalam (apabila ia mula-mula ditambahkan pada repositori):

svn log -r 1:HEAD --limit 1 http://plugins.svn.wordpress.org/your-plug-in-name

Ia akan berfikir sejenak dan kemudian anda akan melihat sesuatu seperti ini:

r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (Mon, 19 Mar 2012) | 1 line

我的插件的第一个数字“520657”是第一个修订版。我们将在下一个命令中使用它，告诉 Git 克隆我们插件的历史记录。将 XXXXXX 替换为您的修订号。

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 期望 SVN 存储库的标准（标签、主干、分支）布局。 '--no-minimize-url' 会阻止它在插件文件夹之外查找。 确保它没有丢失。如果您忽略它，您最终可能会复制整个 WordPress 插件存储库。 -rXXXXXX 告诉 Git 要查找的修订版本。如果你忽略它，Git 将搜索存储库的整个历史记录。修改次数超过 500,000 次。我有一次遗漏了这个，花了大约两个小时。安装完毕后，应该只需要几分钟。

完成后，您应该会发现它在“插件”文件夹中创建了一个名为“您的插件名称”的文件夹。让我们来探索一下。导航到“您的插件名称”文件夹并运行命令以查看存在哪些“分支”：

git branch -a

这将列出所有分支，本地和远程。唯一的本地分支应该是 Master （星号表示这是您所在的分支）。其他分支是“主干”，如果有的话，每个标签都有一个分支（SVN 将标签视为分支，但 Git 比这更聪明）。

转到“本地文件夹”“plugins/your-plugin-name”，您应该会看到插件文件（如果有）。在其中创建或编辑任何文件之前，我们将创建一个单独的分支来处理。

更新：由于 Neerav 和 John Eckman 在下面的评论中指出的问题，上述命令已更新。上面的代码现在反映了 Stephen Harris 的建议。

---

第3步（可选）推送到GitHub

使用 Git 的好处之一是您可以轻松地在 GitHub 上维护插件的版本。这使得其他开发人员更容易访问您的插件，他们可能会提出改进建议，甚至进行自己的修改，您可以将其拉入您自己的存储库中。如果您已经设置了 GitHub，此时您可能希望将插件推送到您的帐户。为此，首先在 GitHub 帐户上为自己创建一个新存储库，然后将其作为远程分支添加到本地存储库：

git remote add origin git@github.com:<your-user-name>/<your-repo-name>.git

“your-user-name”是指您的 GitHub 用户名，“your-repo-name”是指您在其上创建的存储库的名称GitHub。然后你只需推送本地存储库：

git push origin master

---

第 4 步编辑插件：工作流程概要

我们将创建一个新的分支“work”。我们将在这个分支内更改插件、进行更改并添加功能等。这意味着我们的“主”分支保持其原始状态。这允许我们切换回 Master 分支，并再次分支。特别是，假设当您在“工作”分支中开发一些新功能时，您的插件中发现了一个主要错误。您可以切换回您的“主”分支（其中不包括您当前正在处理的任何功能），提交错误修复，然后将其推送到 WordPress 存储库。然后，您可以切换回工作分支并从上次中断的地方继续。 （注意：Git 不会创建文件的副本 - 您的本地文件夹中始终只有一组文件。这些文件包含的内容取决于您所在的分支。）

事实上，为要添加到插件中的每个新功能创建一个分支是个好主意。完成后，您只需将它们合并回主分支即可。如果这导致任何“冲突”，系统会要求您手动解决这些问题。

首先创建一个名为“work”的分支：

git branch work

然后“签出”（转到）分支“工作”：

git checkout work

一条消息将告诉您您已切换到“工作”分支。现在，使用您最喜欢的文本编辑器打开本地文件夹中的插件文件（如果还没有任何文件，则创建它们）。创建一些文件后，您可能想查看更改了哪些文件。您可以使用简单的命令来完成此操作：

git status

这将列出已跟踪和未跟踪文件的更改。可能存在您不希望 Git 跟踪的文件（例如临时文件），但如果您向该文件夹添加了任何新文件，则需要告诉 Git 跟踪它们。您可以使用以下命令执行此操作：

git add <file-name>

我在本地文件夹中创建了两个文件“post-type-archive-links.php”和“metabox.js”，因此我添加了他们告诉 Git 跟踪他们。您必须确保您正在跟踪您的自述文件。

您还可以查看自上次提交以来的更改（这是 GUI 程序变得非常方便的地方）

git diff

一旦您想要将更改提交到本地存储库：

git commit -a -m "Did abc to xyz"

提供提交中包含的更改的（详细）消息。

在进行更改的过程中，您可以（并且应该）尽可能频繁地提交 - 但以合乎逻辑的方式，最好为您所做的每件“事情”进行一次提交。您还应该确保您的提交中没有明显的错误。 “撤消”一次提交既快速又轻松：您可以通过执行另一次提交来逆转前一次提交来完成此操作：

git revert HEAD

（系统会提示您输入一条消息来描述此提交。）

---

第 5 步提交到 WordPress 存储库

假设您现在想要将所有更改推送到 SVN 存储库。在这样做之前，我们需要记住一些事情。 Git 鼓励您经常提交，对于开发而言，这样做是一个很好的实践。不过，您的 WordPress 插件存储库可供分发。它不需要每一次提交。事实上，正如 Otto（WordPress 核心贡献者）警告的那样，它也确实不想要它：

“如果我发现你[分别推送每个提交]，那么我将禁止你访问 WordPress.org。SVN 只需要提交你的最终工作版本，而不是数百个的整个历史记录。您使用 Git 所做的更改。将您的更改扁平化为单个提交。”

为了避免这种情况，当我们准备好推送到 WordPress 存储库时，我们会将所有提交合并为一个提交。有几种方法可以做到这一点。我们将把工作分支中的更改合并（并同时压缩）到主分支中。然后我们所有的更改都会作为主分支上的一次提交出现。然后我们删除工作分支并将主分支推送到插件的 SVN 主干。

首先，我们要切换回 Master 分支：

git checkout master

然后将工作分支更改压缩并合并到主分支中：

git merge --squash work

如果对主分支进行了更改，则合并中可能会出现冲突。系统会提示您在合并完成之前手动解决这些冲突。合并后，提交更改（这一提交将包含我们工作分支的所有提交）：

git commit -a -m "Made changes a,b,c,d"

最后，我们删除工作分支

git branch -D work

如果您有多个分支想要合并，那么您可以对每个分支执行此操作。还有一些替代方法可以扁平化您的历史记录（例如交互式变基），我不会介绍这些方法。

此时，如果您愿意，您可以将最新更改推送到您的 GitHub 帐户：

git push -u origin master

要推送到 WordPress 存储库，我们首先确保我们的本地存储库是“最新的”：

git svn rebase

然后，Git 将获取您的 subversion 存储库，并将其中的任何更改与我们刚刚所做的更改合并。通常情况下，WordPress 存储库不应有任何更改，因此您应该看到以下消息：当前分支 master 已更新。

现在我们可以将更改推送到 WordPress 存储库

git svn dcommit

然后，Git 可能会提示您输入 WordPress.org 凭据。输入后，您的更改将提交到 WordPress 存储库。很快您就会收到来自 WordPress 存储库的一封电子邮件，通知您提交情况。

---

第 6 步标记新版本

目前，这些更改将放在后备箱中。如果我们想标记插件的新版本怎么办？为插件创建下一个版本时，您应该更新自述文件，以便稳定标签指向您的新版本（例如“2.0”）。您还应该在 your-plug-in-name.php 文件中更新插件的标头信息。如果您忘记执行此操作，只需执行上述过程并进行这些更改即可。

一旦您的“主干”完全更新（包括最新版本信息），我们只需在 WordPress 存储库中创建新标签即可：

git svn tag "2.0"

这会将 trunk 中的所有内容复制到 tags/2.0 中（通常使用 svn cp trunktags/2.0 在 SVN 中实现的效果）。

如果您想在本地存储库中标记版本：

git tag -a 2.0 -m"Tagging 2.0"

---

第 7 步（可选）在 GitHub 上标记新版本

与我们对 WordPress 存储库所做的类似，确保我们的存储库同意，然后推送我们的更改和标签：

git pull --rebase origin master 
git push origin master 
git push origin --tags

---

Git 命令的有用资源

• Git 参考（有一个关于“如何像 Git 一样思考”的很好的部分）
• Git 社区书籍
• Pro Git 书籍
• Git Ready（与其说是指南，不如说是“片段”集合）
• SVN 到 Git 速成课程（如果您已经使用 SVN 一段时间，会有帮助）
• Git Magic（Git 的友好介绍）

最后，还有一些可能会派上用场的 Git “备忘单”：此处和此处。

---

GUI Git 程序

窗口

• TortoiseGit（与 Windows 资源管理器集成良好的流行程序）
• msysgit

苹果电脑

• Git 塔
• GitHub for Mac（来自为您带来 GitHub 的人）

Linux / 跨平台

• GitG（这是我使用的）
• QGit
• Git Cola（跨平台）

Atas ialah kandungan terperinci Menerbitkan pemalam WordPress menggunakan Git. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!