Monday, January 31, 2011

Promising and committing

Commit messages suck. If you don’t trust me, enter “svn/git/hg log” in your command line and see yourself. I’m personally tired of seeing endless “Fixes”, “Tests”, etc. in TeamCity build history. Nonetheless, when Mercurial asks me what the hell I was doing for the last hour before it agrees to share my changes with the team, I stare at the text field for couple seconds and, honestly, sometimes end with another “Fixes” poo.

Commit messages should generally follow the same guidelines as status reports at your daily scrum. They must be short, clear and (sometimes) inspiring. This is often not the case because of the huge stream of bugs, change requests, code smells, etc. pumping into your brain at incredible pace.

Experienced developers know that microcommits work best: a small change gets meaningful description easier. The problem is that controlling yourself is hard: when you start hacking your code you normally have a very broad ‘make this stuff even better’ vision in your head. And only in half an hour or more the system asks you to give a name tag to your actions.

Wouldn’t it be better if you could give your commit message before making change? You open up your Twitter favoride IDE and see a nice ‘What’s happening:’ ‘What are you doing:’ text field. You browse your issue tracker, take a look at the scrum board, reflect for a minute and write ‘Implement masterpiece wizard in Photoshop’. And this text is up there at the top of your code editor always reminding of what you’re doing. Now, whenever you switch to something else, you finish this thing first, commit and then change the message to start a new thing.

No comments: