TFS Branching Advice

Question

I am new to Branching and Merging but I have been tasked with making future development on an application possible while still allowing bug fixes to production. Usually I am the only developer on the application unless I am on leave.

I have watched a Pluralsight video on Branching and done some forum/stack reading. I was hoping someone could take a look at my solution proposal and critique. I am concerned I will cause more problems than solutions if I get this wrong

As of Version 1.1.0.0 I have introduced a branching system for future development. Version 1.1.0.0 is our production branch. No changes should appear here except bug fixes. Version 1.2.0.0 is the next version and our development branch.

After completing a development, the development branch will merge to the Application (trunk). The application will be deployed for testing. After sign off the development branch becomes production, the previous version branch will be removed. A new branch will be created for the next version.

For bug fixing, the bugs are fixed against the production branch and merged to the application so when the development branch merges down it also obtains those fixes.

Answer 1

Sounds like 'scenario 2: branch for release" as described by Microsoft's guides.

Its probably the most commonly used branching strategy when using TFS, you have a Main branch from which you make a Dev branch for development, when you're read to merge back, you merge onto Main, perform some testing and then either release from the Main branch, or more commonly, take the Main onto a Release branch so you can make changes to an individual release without having to worry about further updates that have been merged onto Main getting in the way.

Some people never make bug fixes directly on the production branch, they branch from it, make the bug fixes and then merge them back when they've been tested and verified. It makes things easier if you decide not to go with the bug fixes, or have to revert them later as each bug fix release will be a single 'merge' revision onto your release branch rather than a heap of commits.

So, in summary: I would go with 3 branches, one for dev, one for QA (which is also the main line) and another branch for releases. you can tag each release revision if you know you do not have to maintain old versions, but if you do then that Release branch should be a release branch per release, or major version, of your product.

With git and similar systems, you tend to see more of a feature or team branch strategy as merging is a lot easier than on TFS. With something like svn, you tend to see both types.