More and more people are realizing that git is awesome. Although the official WordPress source code still lives in an svn repository, you can contribute patches without having to touch svn ever again.

So, without further ado, here’s how you can generate and manage patches for WordPress Core (it assumes you’re comfortable with the command line).

1. Find a ticket to work on.

Patches need to be attached to tickets. You can browse through existing tickets in trac or create a new one. The Contributor Handbook has more details on the bug tracking workflow.

2. Clone the official mirror.

There’s an official mirror of WordPress on github, so let’s use that:

WordPress has an official git mirror which we can use:

git clone git:// wordpress
cd wordpress

3. Make a feature branch.

Once you’ve got the ticket number, create a branch:

git checkout master -b some-feature/123

where 123 is the ticket number.

Now, make the code changes you need to make and commit them (you can do several commits; it doesn’t matter):

... edit some files...

git commit -am "fixed the bug"

... edit some more files

git commit -am "fixed edge case"

3. Generate the patch.

Here’s the clever part: you can generate an svn-compatible patch directly from git:

git diff master... --no-prefix > some-feature.123.diff

If you want to skip the --no-prefix arg, you can update your gitconfig:

git config --global diff.noprefix true

All you have to now is upload some-feature.123.diff to the trac ticket. Done.

Optional: Publish your feature branch.

If it’s a big feature and you want to get feedback on it – without having to upload a new patch each time you make a change – you can publish your branch to Github, Bitbucket or even your own server.

So, for example, if I went ahead and created the scribu/WordPress repository on Github, all I’d have to do is tell my local clone about it:

git remote add scribu [email protected]:scribu/WordPress.git

After that initial step is done, to publish my branch, I can just do:

git push -u scribu some-feature/123

4. Test other people’s patches.

It’s very likely that at some point you’ll encounter a ticket which already has a patch uploaded by someone else.

First thing you need is an utility that makes it dead simple to download an attachment and apply it as a patch. Just add the following code to your ~/.bash_aliases file:

# Apply a Trac patch.
function tp() {
	curl "$1?format=raw" | patch -p0

And run source ~/.bash_aliases.

Now, here’s how you use it:

git checkout master -b revisions/23497


git add -A
git commit -m "apply"

It gets tricky when a new version of the patch is uploaded and you have some additional commits in your feature branch. I’ll leave that as an excercise for the reader. :)

PS: You might also be interested in my plugin development workflow.