Using Git And Subversion With Wordpress Plugins

Monday, August 25 2014 / Thomas Leen

WordPress uses Subversion for its source control system. If you are going to author a WordPress plugin you are required to use their Subversion repository to manage and publish the plugin.

I am partial to Git/GitHub and would rather use that for source control and collaboration than Subversion. The task here was to figure out how to mix and match the plugin Subversion .svn source control with the GitHub .git system.

Start with Git

Initially you just make your plugin as you normally would in Git. I choose to include a README.md file as GitHub will be using this as the information in the homepage of the plugin. This will be one of the things you will need to smooth over between Git and Subversion. Personally I start the GitHub project, then clone it to my local system. It can be right in your plugins directory or symlinked from another location in your system. Build out the plugin towards the initial release. Once you have it in a state to issue your initial release, tag it in GitHub. You will need to make sure the information file(s) for your plugin are matching your git tags for your stable releases. In this case I usually mark the initial release 1.0.0.

Submit to WordPress

Part of the WordPress plugin submission process is including a link to a zip file of the plugin. GitHub makes this easy, as you can download a tagged release directly as a .zip file, therefore you can link the WordPress plugin submission directly to that download. Once your plugin is accepted you then get a Subversion repository in which to make it all official.

WordPress Subversion

Subversion is going to control your files in a directory structure.

assets/
branches/
tags/
trunk/

Trunk is where your working head will be located. Therefore this is where your Git repo and Subversion repo come together. Copy your entire Git project (and your ".git" directory) to the /trunk of your Subversion repo.

Ignore Git Things

This is the vital step. Before you start committing the subversion repository, make sure you ignore the Git related files. This will be your README.md file, .gitignore (if you have one) and your entire .git directory. Ignore them using the "svn propset" command.

Once you have the files in and Git's files properly ignored, you can then add the rest to Subversion.

Tag for Release

Now it is a matter of getting that 1.0 version out in the WordPress Subversion. This is where the /tags directory comes into play. Make sure all of your plugin readme.txt files and headers have the proper release version. You are going to want to stick to pure number tags for the WordPress Subversion repo. WordPress favors the pure "1.0.0" tags where the Git folks tend to do a "v1.0.0".

Tagging in Subversion is nothing like Git. You need to move out to the Subversion root and make a copy of all the trunk files into the /tags directory like some sort of neanderthal.

svn copy trunk tags/1.0.0 -m "->1.0.0 release"

Your tag name is the name of the directory under /tags. Add and commit the changes and you have your plugin v1.0 published.

Develop in Git, Release in Both

I do all the development in Git then issue releases in Git, then the "official" release in the WordPress Subversion repo. The aim here is to use Subversion as little as possible. At this point I would symlink my subversion /trunk into my development WordPress plugins directory as the plugin's name. Then build out the plugin in Git and only move over to the full Subversion repository in order to do a release.