WordPress 저장소에 플러그인을 호스팅했다면 SVN 및 일부 명령에 매우 익숙할 것입니다. 이 튜토리얼에서는 GitHub에서 대중화된 또 다른 버전 제어 시스템인 Git을 사용하여 플러그인을 게시하고 유지 관리하는 방법을 보여 드리겠습니다.
Git과 SVN은 모두 버전 제어 시스템의 예입니다. WordPress의 저장소는 후자를 사용합니다(WordPress에 호스팅된 플러그인이 있는 경우 이 저장소를 변경하기 위해 "체크인"하는 방법에 익숙할 것입니다). 둘 다 코드 변경 사항을 추적할 수 있지만 수행 방법에는 큰 차이가 있습니다.
SVN은 코드의 단일 "중앙 저장소"(당사의 맥락에서는 WordPress 플러그인 저장소)에 의존합니다. 플러그인을 편집하고 싶을 때마다 로컬 복사본을 만들고 변경한 다음 해당 변경 사항을 WordPress 저장소에 "체크인"해야 합니다.
Git은 분산 버전 관리 시스템입니다. 플러그인의 로컬 복사본이 있을 뿐만 아니라 모든 변경 사항이 포함된 플러그인 저장소의 완전한 복제본도 있습니다. 이제 저장소가 컴퓨터에 독립적으로 존재합니다. 변경 사항을 커밋 및 추적하고, 변경 사항을 되돌리거나, 로컬 시스템에서 플러그인을 다양한 방향으로 "분기"할 수 있습니다. 플러그인을 업데이트하려는 경우에만 변경 사항을 WordPress 저장소에 푸시하여 공개하게 됩니다.
이 튜토리얼에서는 이미 WordPress 플러그인 저장소에 호스팅된 플러그인이 있거나 적어도 호스팅 요청이 승인되었다고 가정합니다. WordPress에서 플러그인을 호스팅하는 방법을 잘 모르는 경우 WordPress 플러그인 저장소에 게시하는 방법에 대한 기사를 읽어 보시기 바랍니다.
SVN(및 일반적으로 분산 버전 제어 시스템) 대신 Git을 사용하는 것에 대해 많은 논쟁이 있습니다. 이들 중 다수는 Git과 SVN이 변경 사항을 추적하는 근본적으로 다른 방식에서 비롯됩니다. CodeForest의 Git 및 SVN 기사는 Git 및 SVN에 대한 훌륭하고 심층적인 분석을 제공하지만 WordPress 개발자를 위한 내용은 다음과 같습니다.
git svn
리소스)에 자세히 설명되어 있습니다. Git 설치 방법은 운영 체제와 사용 가능한 GUI 프로그램에 따라 다릅니다. 이 튜토리얼에서는 명령줄을 통해 모든 작업을 수행합니다. 여러분도 똑같이 하시길 권장합니다. 기사 끝부분에서는 사용할 수 있는 몇 가지 GUI 프로그램을 추천하겠지만 일반적으로 저장소의 분기를 시각화하는 데 도움을 주기 위해 이러한 프로그램을 사용합니다.
" 폴더에 넣어두겠습니다. 거기에 도달하면 Git에게 플러그인을 찾을 수 있는 위치를 알려주고 싶습니다. 이 글을 쓰는 시점에서 WordPress 저장소에는 거의 20,000개의 플러그인이 호스팅되어 있으며 500,000개 이상의 개정판이 있습니다. 우리는 Git이 플러그인을 찾기 위해 각 단계를 거칠 때까지 기다리고 싶지 않습니다. 먼저, 플러그인의 시작 버전을 찾습니다(전체 기록이 되기를 바랍니다). 이를 위해 플러그인의 첫 번째 로그를 얻습니다(처음 저장소에 추가되었을 때): 으아악 잠시 동안 생각한 후 다음과 같은 내용이 표시됩니다.
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 的建议。
使用 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
我们将创建一个新的分支“work”。我们将在这个分支内更改插件、进行更改并添加功能等。这意味着我们的“主”分支保持其原始状态。这允许我们切换回 Master 分支，并再次分支。特别是，假设当您在“工作”分支中开发一些新功能时，您的插件中发现了一个主要错误。您可以切换回您的“主”分支（其中不包括您当前正在处理的任何功能），提交错误修复，然后将其推送到 WordPress 存储库。然后，您可以切换回工作分支并从上次中断的地方继续。 （注意：Git 不会创建文件的副本 - 您的本地文件夹中始终只有一组文件。这些文件包含的内容取决于您所在的分支。）< /p>
事实上，为要添加到插件中的每个新功能创建一个分支是个好主意。完成后，您只需将它们合并回主分支即可。如果这导致任何“冲突”，系统会要求您手动解决这些问题。
首先创建一个名为“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
（系统会提示您输入一条消息来描述此提交。）
假设您现在想要将所有更改推送到 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 存储库的一封电子邮件，通知您提交情况。
目前，这些更改将放在后备箱中。如果我们想标记插件的新版本怎么办？为插件创建下一个版本时，您应该更新自述文件，以便稳定标签指向您的新版本（例如“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"
与我们对 WordPress 存储库所做的类似，确保我们的存储库同意，然后推送我们的更改和标签：
git pull --rebase origin master git push origin master git push origin --tags
最后，还有一些可能会派上用场的 Git “备忘单”：此处和此处。
위 내용은 Git을 사용하여 WordPress 플러그인 게시의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
