Version Control Commandments

Version Control is a staple in a developers day-to-day routine. Follow these guidelines for proper versioning.

Last Updated: • Develop •

Version Control Library

Using version control is vital to a development shop. Even though I am one developer, I have a subversion code server in my basement that I constantly use. If I write a bad piece of code, it feels so good to rollback to a previous version of code instead of trying to wrack my brain figuring out what code to back out.

In a team or corporate environment, though, you may have some developers who are new to the team and are unfamiliar with version control software like CVS or Subversion. I know those coming from Microsoft SourceSafe to CVS had some troubles adjusting.

These commandments are definitely required for any new or seasoned developer.

  1. Thou shalt not break the build
    If you learn anything from these commandments, it is this: DO NOT CHECK IN CODE THAT WILL BREAK THE BUILD! It's truly amazing that one person can bring an entire team (and project) to it's knees.
  2. Thou shalt do an update before a commit.
    Developers who are new to version control systems may not understand updating before checking/committing code. They want to immediately check their code in before they lose it. The down side is that if numerous developers committed code on that one source code file, and you commit (overwrite) their changes, you may have 1+ developers pretty upset with you. If you continue to break this commandment, I'd look for another job at that point.
  3. Thou shalt practice theoretical coding
    When your build breaks (and it will), remember the days of coding in a vacuum. Do not check any code in unless you know for a fact that the build will compile properly.
  4. Thou shalt implement a continuous integration server
    When you check code in, the continuous integration server will immediately compile the project. If there is an error, an email is sent out to the user who last checked the code in and they are notified that THEY have broken the build. Usually, the process involved giving the culprit a item of shame to let others know that they broke the build.
  5. Thou shalt trust thy merging tool
    When there is a conflict in the project code, have a solid understanding of not only how to merge code from one source file to another, but understand how your merging tool functions.
  6. Thou shalt tag and tag in moderation
    When a project build is at a stage where everything is stable according to the lead developer and project/product manager, make sure all code is checked in, builds, then freeze the code, and attach a tag with a version number to mark the checkpoints of your project. It's much easier to rollback to a tagged version of the product instead of guessing where the change was made.
  7. Thou shalt minimize the duration and amount of branches
    In a large team of developers, multiple groups may break off into numerous branches of development. Unless you have a version control guru, merging these issues will be a nightmare. The more branches you have, the worse it will be to merge the changes into the trunk. If you shorten the duration (day/week/month) of the branches and have a small amount of branches in the project, the merging will be less of a nightmare.
  8. Thou shalt commit changes daily
    If someone hits the lottery (the bus scenario is too gruesome) and leaves the company or if someone is sick for a day or two, you forgot to have your latest code committed. While you're out sick and a deadline looms, guess what? Someone else may go through code and notice yours in missing and start fixing/coding your part that's already done. You know how this will end so I'll just say commit your changes daily.
  9. Thou shalt run tests on code
    Every time code is pulled from the code repository that doesn't have a tag attached to it, quality assurance tests should be executed against that build. This confirms confirms that the code is stable enough to release into the testing or production environment.
  10. Honor thy assets by committing all related material
    This is geared more towards designers, DBAs, and project managers along with developers. Commit all of your assets including graphics, documentation, specifications, DML statements, SQL data, and other additional materials. Once committed and tagged, you'll be able to sleep better at nights.

Did I miss any? Let's discuss it below in the comments.

Did you like this content? Show your support by buying me a coffee.

Buy me a coffee  Buy me a coffee
Picture of Jonathan Danylko

Jonathan Danylko is a freelance web architect and avid programmer who has been programming for over 20 years. He has developed various systems in numerous industries including e-commerce, biotechnology, real estate, health, insurance, and utility companies.

When asked what he likes to do in his spare time, he replies, "Programming."

comments powered by Disqus