Home/ Questions/Q 792363
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T21:58:48+00:00

I work in a group of 4 .Net developers. We rarely work on the

  • 0

I work in a group of 4 .Net developers. We rarely work on the same project at the same time but it does happen from time to time.We use TFS for source control. My most recent example is a project I just placed into production last night that included 2 WCF services and a web application front end. I worked out of a branch called “prod” because the application is brand new and has never seen the light of day. Now that the project is live, I need to branch off the prod branch for features, bugs, etc…

So what is the best way to do this?

Do I simple create a new branch and sort of archive the old branch and never use it again?

Do I branch off and then merge my branch changes back into the prod branch when I want to deploy to production?

And what about the file and assembly version. They are currently at 1.0.0.0. When do they change and why? If I fix a small bug, which number changes if any? If I add a feature, which number changes if any?

What I am looking for is what you have found to be the best way to efficiently manage source control. Most places I have worked always seem to bang heads with the source control system in on way or another and I would just like to find out what you have found that works the best.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is good practice to have a separate branch for supporting each released version, and another for continuing the development. This way you can always produce bug fix releases for older versions independent of the new features you are working on on the main branch.

    In the long term, it is better to keep the main branch as your development branch, and create a separate support branch for each specific release; this keeps your branch paths short. (I have worked on a project where the path of the actual work branch was something like main/release_1.0/release_1.1/release_1.5/release_2.0/release_2.1… you don’t want to go down that lane 🙂

    Of course, you need to periodically merge any fixes made on the support branch(es) back to the main branch – at least before creating the next release. My experience is that it is definitely not recommended to leave merges till the last minute – the later you merge, the bigger the differences between the two branches grow, so the higher your chance of running into trouble is. Automatic merging tools give up if the complexity of changes to merge gets over a certain threshold… and hand merging is not fun.

    Versioning can be, to a large degree, a question of personal preference. On a small project you may be happy with a major.minor version scheme, on a larger project you may want finer control using patch and/or build version numbers too.

    You need to work out a version policy and then stick to it. E.g. if you use a major.minor version scheme, increment the minor version for bugfix releases, and the major version for new feature releases.

    • 0