Got Commit

Although Automattic uses Subversion for source control both for its themes and plugins, I keep a number of my plugins in Git repositories during development.

Additionally, 8BIT uses GitHub to keep track of all of our source code, issues, milestones, and so on. When it’s time to make a commit, we usually sync the Git repository with its Subversion equivalent.

I’ve used a number of different source control systems during my career – some distributed, some not – and I’ve never been someone who fights a so-called religious war over which is better. Each source control system has its advantages, disadvantages, and each one fits differently within the context of how a person or a team operates.

Currently, I really like Git but a lot of that has to do with how GitHub, the site, fits into my workflow. Sure, there are things about Git that I like, but it’s GitHub’s organization that fits how I do work.

Anyway, overtime I figured I’d discuss my thoughts on WordPress source control. In this post: commit messages.

Earlier last month, Ryan McCue shared the following tweet:

And he’s right. This is one thing that I’ve seen misused for sometime (in fact, I’m guilty of it as much as it pains me to admit it).

The short of it is this: Git encourages small changesets and, thus, short commit messages so that you can easily roll back to the “last good state” at any given time. If you’re committing a large changeset (and longer commit messages), then you’re robbing yourself the ability to do this.

The contrast to, say, Subversion is that its changeset usually consist of larger sets of changes.

But here’s the thing: it doesn’t have to be that way.

Although git certainly encourages shorter commit messages, it doesn’t prevent you from making larger commits. Similarly, just because we – or at least I – usually commit larger changes to Subversion, I don’t have to do so.

So regardless of whatever source control system, you and/or your team choose to use, I highly recommend follow Ryan’s advice and keeping your commit messages – and, thus, changesets – small.

This goes a long way in being able to roll back your application should something break, it keeps a more detailed history, and it makes it easier to pinpoint when and/or where a bug was introduced.

Note that the featured image is from the Got Commit? Shirt Site.. Kinda cool :).


Join the conversation! 7 Comments

  1. Writing and committing short fragments is normally not how I work, so I find breaking things up in such a way can make more less efficient – although as you note it has many benefits!

    One of the things I love to counter this is “git add -p” – which means I can still work as I want, but can easily split up my commits into sensible logical chunks (See for an overview).

    It’s been really helpful in migrating me to sensible commits from monolithic ones, and is the main reason I now use git for all my development over svn …

  2. I would be totally interested in how you set up a new WordPress project. Meaning, do you create the entire instance (including core) as a git repo, or just the theme or plugin? If you just do the theme or plugin, how do you dev on that, but then maintain an up-to-date core?

    I know that Mark Jaquith has WP-Skeleton and others have pulled the wp-content and configs out of core and left core as a standalone git submodule, but I’m wondering if there’s a “neater” way of doing it where there isn’t so much ripping apart of the WP directory structure.

    • This is good content for a post. I’ll see if I can’t queue something up for this within the next week or two.

      It varies from project to project, but there are definitely some consistent things I do so I’ll try to document it here.

      Thanks for the idea, Jason!

      • Oh ok, no problem, can’t wait to see it. I’ve been messing around myself and also trying to get a glimpse into other devs and how they are doing it.

        Basically I have 2 scenarios for setting up a local WP dev
        1. An instance where I just need to create a plugin or run some test scripts on. Here I don’t necessarily need to have the Core in the repo, but it’s more important that I am able to control/upgrade the version if needed. Also to be able to drop the version down a few notches if the case doesn’t require the latest and greatest.
        2. An instance where it’s a new site for a client. Now in this case, I would want the Core in the repo, but I want to be able to maintain and upgrade the core using Git rather than clicking the button in the Admin. But also maintain the theme or plugins inside Git as well.

  3. I really love this blog. You write about very interesting things. Thanks for all your tips and information.

  4. I am also willing to learn GIT a bit.
    But at the moment I need a way to create a staging site and push it to live site. RAMP is a solution but are there any decent free plugin that does the work.
    Can anybody please advise.

Leave a Reply