Branching Strategy

Tuesday, November 24, 2009 2:35 PM

Check out for some good discussion about branching strategy.

This is in reply to a question about our branching strategy on my current project at work.

  • Main - similar to "trunk". Contains the latest and greatest code and is always ready to deploy to production.
  • Dev - similar to "branches". Any feature that will take more than one check-in to finish should be done in a branch. This is to facilitate the most important part of main – always ready to deploy. And of course, we check-in frequently as a good practice so branching is pretty important.
  • Prod - similar to "tags". Contains the code that is currently in production. If it's a web app, you only really need one branch in here unless you think you might actually roll back to a previous version. This branch is useful when you need to immediately fix a bug in production but aren't quite ready for main to be deployed. Just because main can technically be deployed, doesn't mean the business is ready for it. The reason you see so many versions in our prod folder is pure laziness. It needs to be cleaned up big time.

And for the other two questions:

When you branch, you need to remember to check in the code you just branched. The icon mentioned is TFS's way of telling you that you haven't checked in the branched code yet.

We get the version number from the version of our core library. Many projects will use a shared settings file or something to ensure all the libraries within a solution have the exact same version - much cooler than the way we do it :)

Hope that helps!

Tags: architecture, work