I initially encountered version control in my 4th year of programming, when the lead developer of the company I worked at had implemented Subversion as a code backup solution on our local testing server. As we were all required to use Windows at the time, we mostly just installed TortioseSVN, so my command line Subversion knowledge is limited.
A few years later, at another company, I was introduced to Git. At the time GitHub was in it’s infancy, but we used it internally for revision control and production deployments. This was also around the time I switched to using Ubuntu as my main OS, and learning the joys of the terminal. Since then, every team I worked with has used Git and either Bitbucket, GitHub, or GitLab. This means that I can use Git on the command line with reasonable success, and can work with branching, code reviews, and submitting/merging pull requests using the web interfaces of these platforms, with GitHub probably being the one I am most used to.
Back to the point, this meant then when I got into developing for WordPress at the end of 2015, and found they all used Subversion to manage both core and plugin/theme repositories, I was a little out of my depth. Managing plugins was easier, I could keep the my version control using Git, and then just memorise a couple of commands to push the latest updates to the plugin repository. Getting into core development was a little trickier, as it was all managed using Subversion. To be honest, it’s been one of the reasons I’ve struggled to get into WordPress core development.
All this changed in March of this year, when it become possible to associate GitHub accounts with WordPress.org profiles and documentation was added to WordPress core developer handbook on how to use GitHub pull requests for code reviews related to trac tickets in WordPress.
I had the code, and the comfort in using Git, and the documentation was very clear as to the steps to follow. All I had to do was make it happen.
Setting up the development environment
I’ve blogged about this before, but I use a very simplified LAMP stack for my local development. I know, I’m old, but it’s easy to understand, fast, and it just works. It does help that my base OS is Ubuntu, and the actual LAMP set-up is really easy, especially if you have the amazing tutorials over at Digital Ocean.
What did concern me was how much work I might have to do to get the wordpress-develop GitHub repository installed and set up on my local environment, to be able to test anything I added. To my surprise, it was a breeze. Using the same setup script I use for my client projects, I created a wordpress-develop local site and cloned the wordpress-develop repository into the local wordpress-develop site directory.
The WordPress source code resides in the /src directory, so I browsed to the local .test domain which my setup script creates (https://wordpress-develop.test/src) and was surprised to see a little ‘reminder’ screen, telling me I needed to install the npm dependencies.
Fortunately I already had npm installed locally (having recently needed it for the Seriously Simple Podcasting player block) so I just needed to install and build the required assets with npm install and npm run dev.
After that, it was the good old famous 5 minute install I’m always used to, and within a few minutes I had the wordpress-develop code up and running on my local environment.
The actual Git process.
This is all documented in the core handbook entry on Git, but once you have the GitHub repo cloned, creating a patch to submit to a ticket is pretty straightforward.
Firstly, it’s a good idea to create a working branch for your code. The handbook recommends using the ticket number as part of your branch name
git checkout -b 30000-add-new-feature
Once you have your working branch, you can make your changes to the code, and use the git add and git commit commands you’re used to if you’re comfortable using Git. You’re able to view the status of your changes, using the diff tool. This outputs all the changes between the main branch, and your working branch.
git diff master 30000-add-new-feature
When you are ready to submit the patch, you can use the diff tool again, and simply pipe the changes to a .diff patch file.
git diff master 30000-add-new-features > 30000.diff
If there are already patches attached to the trac ticket, you can use this tool to create updated patches.
git diff master 30000-add-new-features > 30000.2.diff
To be honest, this is probably very similar to how it works in Subversion, but being able to use Git commands and Git branches, when you’re more comfortable with Git, makes it much easier to get started.
You can also use GitHub pull request for code reviews on patches, but that’s a topic for another day.
This is all pretty exciting for me, because it lowers the barrier for me to contribute directly to WordPress. I’ve already got two new tickets in trac that I’ve submitted patches to, and I’m looking forward to being able to contribute back to WordPress core in the coming years.
Leave a Reply