While this worked very well it does have one big drawback, it means I can’t put the themes and plugins I use into version control since they are inside the official svn checked out dirs.

Recently I’ve been switching to git and thought that switching the WordPress install to git would solve this problem. My first attempt was using the git-svn tool to convert the upstream subversion repo to a local git one. This would have enabled something very similar to what I was doing before with the “svn up” command, one git-svn command would have updated the code to the latest version.

The problem with that idea is that the WordPress repo contains over 10,000 revisions. Duplicating that via git-svn would have taken days and all I really need is the current version. I looked for a while to see if there was a way to limit the number of revisions copied but apparently there isn’t.

So, I fall back to searching the web and I came across Tracking WordPress using Git, which is pretty close to what I wanted. It is a little bit more work to do the updates that way but not that much.

What I need though is an internal dev version of the site on one branch, the live site on another and the upstream code on a third. Then I need to push the live branch to my web host, and I also need to be able to pull any emergency fixes I make direct on the live site back into my local git repos. Pushing changes with git is a little tricky since a push doesn’t update the checked out files, but I found a helpful blog entry A web focused git work-flow, which gives me exactly what I want.

The one remaining problem I have is I don’t completely understand how git merges work. The internal dev branch and the live branch have some differences I don’t want merged, paths etc. Whenever I try to merge the branches though it invariably automatically changes one branch to exactly match the other and auto-commits. I’m sure git can do this, merge some changes but not others without manual intervention each time but I haven’t worked out how yet.

Okay, after a bit more time working with this setup it seems the problem is bi-directional merges. Merging from dev to live works great right up until the point I do a merge from live to dev, at which point git seems to forget that there is some stuff that I don’t want merged next time I go from dev to live. Preventing the auto-commit makes this manageable though, to do this you (confusingly) need to specify “–no-commit –no-ff”. You’d think the no-commit would be enough on its own but apparently not.

So in my local copy I have 3 branches:

• master, the extracted WordPress tarball
• internal, my internal development/test site
• external, copy of the live site

I have the following settings set on my local git repo (private details redacted) to make pushing changes easier, I don’t have to remember any parameters for the git push command.

branch.internal.remote=origin
branch.internal.merge=refs/heads/internal
remote.external.url=ssh://$USER@$HOST/~/$GIT_PATH
remote.external.fetch=+refs/heads/*:refs/remotes/external/*
branch.external.merge=external
branch.external.remote=external

Then on my web host I have the bare git repo at $GIT_PATH that gets pushed to, and the actual live site. Both of those only have the external branch.

To update the live site all I need to do is make the changes on my local copy of the external branch, then run “git push”. This sends the changes up to the bare repo, which then automatically updates the live site.

Then when a new version WordPress gets released, what I will do is

1. Switch to the master branch.
2. Delete everything except the git dir.
3. Unpack the new files to replace the deleted ones.
4. Commit those to git and it will work out what has changed for that release.
5. Change to the other branches in turn and git merge from the master branch.

This should update me to the latest release without losing any of my local themes, plugins or mods.

I could go one step further and create “upstream” branches for each plugin I use in a similar manner to the main upstream WordPress branch. That would allow me to mod the plugins, and still upgrade them easily. I’m not going to do that though (yet) as I think it would be more trouble than it is worth.