Commitment is it’s Own Reward

I’ve often spoken with other developers about the subject of VCS(Version Control System) and how they go about managing it for certain projects. For something that is so critical to keeping a good development flow as well as saving you alot of headache down the road, a surprising number of developers(particularly newer developers) don’t even use it. In a software world of ever increasing complexity, developers that don’t use VCS of some kind will soon find themselves out of jobs.

A common question that I get is, “Okay Trey. I’ve made my git repository, but when do I commit?”. The answer is.. well it depends. I particularly like this answer by Neil Butterworth.

“You commit when you have reached a codebase state you want to remember.”

For those who are still scratching their heads, basically whenever you might think you might need to go back and look at it whether it be to remember what you did for that feature or if you actually need to rollback. I personally like to commit whenever I’ve completed a thought or feature. This helps with debugging as I can roll back my code incrementally and find at what point did something go wrong.

VCS is there to keep you organized, keep your code atomic, and help you out with troubleshooting.

Up to this point I’ve talked pretty exclusively about Git, my VCS of choice. But that doesn’t mean there aren’t viable alternatives. Mercurial comes to mind and while I don’t use it simply for taste reasons, there are without a doubt reasons to use it over Git. But I’m not here to stir some flame war over different VCSs.

And don’t adopt a tool just because it sounds cool. That kind of thinking is dangerous, where you adopt something because other people do it or it looks cool rather than because it offers some functionality that would genuinely solve an issue or help development. In those cases I would measure your tooling against the Agile Principles, if they don’t hold up it’s time to rethink.

I think you should pick the one that works best for your project and doesn’t hinder you but rather helps you develop. That rule should carry across your tooling. If you feel like some tooling is slowing you down rather than speeding you up, question it. Challenge the tools you use and never be afraid to ask, “Why the heck am I using this?” If the answer is, “Because that’s why we’ve always done it.” It’s time to start looking at alternative methodology.

Leave a Reply

Your email address will not be published. Required fields are marked *