Think before you commit
Posted by Kevin Owocki | Posted in Technology | Posted on 21-11-2009
Version control is important, oh so important for managing changes to your codebase. Whether you’re a solo developer, or a team, you NEED to be able to track the evolution of your code.
Tracking down changes to code is one of the most important things I do, day to day. Though, sometimes it’s way too hard to reverse engineer a developers intentions if their commits messages or changes sets are opaque. Other times, it’s hard to match a specific commit to business requirements
I think it’s time to introduce some best practices for ensuring useful commits:
- Match the commit message to your requirement story title. When I’m committing a change for a story in our requirements management system called ‘Inbox management iteration 1′, my commit message will likely be ‘Inbox management iteration 1 – Commit #1, {brief search-friendly description of features}’
- Make small atomic commits A commit should be one cohesive logical unit. I’ve found that by making small, granular commits every time I complete something, it’s must easier to reverse-engineer my intent later.
- Compile before you commit It sounds so basic, but sometimes code gets committed with syntax errors.
- Test before you commit Again, sometimes code gets committed that hasn’t been thoroughly tested. This is extremely important for changes to foundational pieces of a codebase.
- Compare via diff before you commit Comparing via diff is a great way to view what you are actually changing from a higher-level view. It’s useful to make sure what you’re changing makes sense to you and your team, if they ever have to come back to it.
If you and your team follow best practices for your commits, then it can save everyone a great amount of time and effort.
Does your commit process need improvement? Do you think before you commit? Leave a comment below or via twitter here.







