Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Effective Version Control
Your development machines have a baseline configuration and everything is being backed up daily. What more could you need? Simple—version control.
Configuration control and daily backups give you reasonable protection from hardware failure. Version control gives you a measure of protection from the mistakes you make while developing software. Version control helps in many ways:
Many developers can work on the same project without overwriting each other's files. Most text editors are fairly dumb—the last person to save wins. This means that it's really easy for two people to both work on the same file and then the next morning the unlucky one will discover that all of his or her edits from yesterday are missing. Version control software prevents this problem, either by requiring developers to "lock" the file before they change it, or by warning of incompatible edits when the changes are resaved to the version control system.
You can tag a related set of files as a coherent working version. When you get a set of classes all working together correctly, it's great to be able to label that related set of files and then continue making changes, knowing that you can always re-create that working set of files when needed.
When you make a mistake, you can easily revert to a known working version. Sometime or other you will try out a design idea and discover it doesn't really work well. Rather than lean on the undo key in your editor for 10 minutes, just check out a clean copy of the most recent version of the file.
Version control allows you to see who made what changes to a file. Some days, code that you know was working just breaks. By using the version control system to see what files have been changed recently, you can often shorten the time it takes to hunt for the mistake. Sometimes you'll be lucky and it will just be a matter of asking the person who made the last change whether he or she has any idea what might have gone wrong. Other times, you might have to go as far as looking at the differences between two versions of the same file before you can discover the mistake.
To get all of these benefits, you must remember to check your work in frequently. I recommend checking in your changes every 30 to 90 minutes. This encourages me to make small, controlled changes to the code. This is very easy when using test-driven development (see Part 2 of this series), but can be harder to manage when using more traditional programming practices.
Whatever you do, don't delay checking in your changes beyond the end of your normal workday. Making very big changes means that you won't have any intermediate steps to revert to if (or rather when) you make a mistake late in the day. It can also mean a lot more hassle for the rest of your team when you eventually check in your files, since they suddenly have to deal with a large number of changes. Even worse, you might have locked someone out of a file that he or she needed to change, or your changes might be incompatible with other changes that have been made during the day.