Version control is a really important tool that I use every day. It is not only is a great tool for storing and keeping track of code. It can make you a efficient developer by forcing you to think about your what changes you are making to your code, because once we think about what we are doing it makes us more focused on the task at hand.
This strategy is different than many other “development” strategies, because it never defines what you develop, how you develop, or even how you manage a project. The only focus of this strategy is committing atomic changes, and logging those changes in the commit comments properly, and finally only commit code that builds. Using version control in this fashion produces a usable change log that can be used to track progress between revisions.
- Commit only one change a time.
- Commit only working code.
- Comment your changes effectively.
Commit only one change a time. We should only commit one atomic feature, fix, update at a time. If you have 12 bug fixes in the queue, every bug fix should be a commit. If you have a new feature such as a new management screen, it would need to be broken in to it’s basic parts. New data access code, updated business logic, new ui screen, new ui code, etc.
Commit only working code. This is a no brainier, commit only code that builds, and does not error when you go to it. If you need to commit code that breaks, comment it out. If it’s such a major change it will break the build, then you need to branch. This keeps the integrity of build, and the project’s trunk intact.
Comment your changes effectively. Commit log comments are not useful unless they communicate something quicker, and more effective than looking at the file log. I should be able to look at the commit log, and see what sections were touched in less than 15 words. In earlier posts I outlined a strategy for useable subversion comments, so I won’t digress.
Using this strategy has made me a more effective developer, by addressing some of my weaknesses. If you are not thinking about source control in terms of development strategy you may be under utilizing the the tool. Instead of searching for the next new tool, we should look at what we already have, and how to use those more efficiently.
