In the past, I’ve discussed the importance of using version control and also ways for structuring your subversion repository. Today, I’d like to cover an important best practices with version control whether you are a lone wolf developer or you frequently travel in a pack.

After you’ve wrapped your head around version control (and I’ll be honest, it baffled me the first time I was forced to use it), there’s only a couple more best practices you need to be aware of to get the most out it.

Don’t Commit Conflict Bait

Conflict Bait is basically something that’s going to generate conflicts pretty much any time a team member updates from the repository. A good example of Conflict Bait is the swf file that your project generates when you build, or intermediate build files that your IDE might generate. Don’t put these in the repository, because you will publicly mocked by your more senior team members when they are forced to remove them.

Exceptions: This one isn’t such a big deal if you’re the only person working on a particular project. When you are rocking it solo, it can sometimes be useful (read: lazy) to let version control track your builds so can look up old versions without checking out a fresh copy of the whole repository.

Write Comments In Your Commit Message

This one is a bit of a “Duh, really?” When you’re going back over a log of 1,000 commits, you’re going to be sorry you didn’t leave the breadcrumbs to help you track down that bug in that feature you haven’t tested in over 3 months.

Only Commit Verified Builds

Don’t commit code that breaks trunk. If you do, you will be shot and beaten. Resist the urge to commit that untested feature right before you sign off for the day. This is the absolutely WRONG thing to do. Perhaps your fellow coders were planning a code binge that night and your last minute tweak sends them on a 4 hour bug hunt instead. Don’t do this to your teammates.

Exceptions: This again is more applicable in a team environment.

Close Your Open Files Before Updating

Sure, Flash Develop or Flex Builder will usually warn you when a file has been externally updated and ask you if you want to reload. Usually. In my life, I’ve wasted at least 2 day’s work undoing the damage caused by accidental overwrites after the IDE failed to recognize an update changed a file. Close your open files, then update. Don’t be that guy, really.

Make Your Commit As Small As Possible

You might think you’re awesome by making monolithic commits, but you’re really just overcompensating. The best commits are ones that are as granular as possible. This is a good practice for numerous reasons, and one that helps support many of the other best practices already mentioned.

1. It keeps your project manager informed of your progress. If you’re making commits every 5 days, it doesn’t matter how big they are, you still look like you are not pulling your weight when your project manager gets his daily commit log and your name isn’t on it.
2. Your commit becomes easy to refer to because of its unique revision ID. It becomes an entity that can be referred to, entered into bug databases, etc.
3. When you’re digging through logs that have one succinct change applied to a single file, it is far more useful than a commit log that is 9 pages long and involved 30 files, which may or may not be related to your current search.
4. Your commit becomes easy to undo. Let’s say you really screwed things up and totally broke a feature (and then went to bed for the night). Your team members can see quickly from your commit log that revision 324 was a granular commit related to that feature and is likely the source of the issue. They can roll back the change and move forward while just cursing you briefly.

I’ve been using version control in a team environment for about a decade now. Hopefully this helps you benefit from some of that experience.