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:
Any time you write “also” in a commit message, you’re almost certainly doing it wrong.
— Ryan McCue (@rmccue) December 16, 2012
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.