I'm a contractor that has recently started with a firm.

Team is 3 developers consisting of 2 junior to mid level devs, with another at the same level starting soon, and myself (6 Years xp). For both the existing developers it is their first job out of university/college, and they've never had a senior developer overseeing their work before.

There is no explicit Version control policy. Developers do all the development on the trunk and then deploy to production direct from their development machines. The existing team are not familiar with branching.

I'm changing all this and introducing CI, TDD test/staging/production servers etc, along with a version control policy to compliment this.

Source control system is TFS, which i've never used before. It's configured as one giant repository.

I've written down a few pointers for them, but is there anything else i should be adding/ amending, bearing in mind the experience of the team?

Version Control Policy

Development is done on the trunk

If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.

Release branches created for production code. That branch should only contain stable code. We can either have one release branch that gets updated from the trunk once per sprint, or we can make a separate release branch for each week.

If a urgent bug fix affecting production code needs to be made, then it gets made on the release branch, and merged back into the trunk.

If we adopt the one release branch strategy then the trunk gets merged into the release branch once per sprint towards the end of the sprint.

If we adopt the seperate branch per release strategy, then the trunk NEVER gets merged into the Release branch

In some scenarios it may be necessary to make the bug fix twice on different branches, if branches have diverged too much. If we are doing short sprints then this shouldn’t happen too often.

I plan to have three servers. Test environment that is always running the latest code in the repo. A staging environment which is running the newest release candidate for staging/testing Release Candidate code and UAT purposes, and the production environment.

The reason why i plan to do this is that so far the client has only done internal software. The newest project is for a high profile media client, and my feeling is that the team need to adopt a more professional development model than what they do at the moment.

For example at the moment, a user may phone up the team with a bug report. The devs locate and fix the bug, do a quick test eyeball test on their own machines and then deploy straight into production. No automated testing or anything.

In hindsight i think the feature branch is a step too far and i'll remove that.

So essentially it comes down to a) no branching at all) b) a release branch and the trunk, and c) a release branch per release and the trunk.

I was leaning towards the latter. My initial thought would be that i would have both a release candidate and a release to be live on separate servers(UAT/Production) at the same time, but effectively the trunk is the release candidate at any point in time, so a branch per release is leaning towards insane. My only thought would be if we didn't want our stakeholders to see development code then we might need a separate release candidate branch, but YAGNI and all that.....

  • 3
    did you consider adding an explanation of why you picked this way? say, similarly to how it is done here. Also, did you check "Microsoft Team Foundation Server Branching Guidance" (referred eg here)?
    – gnat
    Jun 16, 2015 at 11:42
  • 3
    Try this one
    – gbjbaanb
    Jun 16, 2015 at 12:01
  • 1
    Bear in mind that i'm using TFS not a DVCS like GIT. That seems a bit git specific.
    – MrBliz
    Jun 16, 2015 at 12:44
  • 2
    The end of that link says: "Everyone works off of trunk. Branch when you release code. Branch off a release when you need to create a bug fix for already released code. Branch for prototypes." I would suggest that for a simple beginning you just tag releases when you are reasonably sure they are Done. Unless you have multiple developers working on multiple features there is not much need to have more than 1 branch. Everyone adds features, everyone fixes the release candidate, everyone agrees when it is ready to tag. That means you only have to hand branches for bug fixes later on.
    – TafT
    Jun 16, 2015 at 15:31
  • 1
    I'm uncomfortable putting this as an answer, because it's too opinion based, but I have had great success convincing people to use a "last known good" tag (LKG), which is a moving tag on the trunk identifying the last "blessed" version (CCB, testing, etc.). Developers are told releases will be done from this LKG tag, not the head of the trunk, and beyond that, they are free to use whatever approaches make sense to them at the time. I have found this pattern to spontaneously generate feature-branches when the time is right, without any up front effort or extra work on the developers' parts.
    – Cort Ammon
    Jun 16, 2015 at 16:30

3 Answers 3


For a team of 3-4 devs, you're proposing WAY too many branches.

Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost.

Keep in mind that the only real benefit to a branch is code isolation. That means you need a concrete reason to want to have the code isolated.

Having a separate release branch for every sprint is insane. Why do you need the code from one sprint isolated from the code for the next? Why not just have a single stable release branch that gets carried forward with each sprint?

If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.

Almost any non-trivial new feature is going to take at least a week in real time after you account for development, developer testing, daily interruptions and other activities, etc.

Also, what's a "regular merge"? Daily? Weekly? Every merge you do takes time - you need to make sure the target merge branch builds & runs after your changes. On a small team, frequent merging is a lot of overhead.

We have a team of 4 developers working on a 1+ million line codebase and this is how we operate:

  • Main branch where all development is done
  • One branch per major release (done about once per year)

The one major rule is: don't check in code that doesn't build.

That's it. Simple, easy to understand, gets the isolation we need (at any time we can create a release build for any version).

The upsides to having all development work done on one branch:

  1. Developers are always in-sync with each other. No painful merges because two developers were off on their own branches for weeks creating incompatible changes.
  2. Broken builds are found on the same day. We have a nightly build that runs the latest code on main. If someone does check in code that doesn't build for some reason, we will know right away.
  3. With everyone always working on the same code, in increases the chances of a bug being found sooner rather than later.
  4. No merge overhead other than targeted fixes to release branches. On a small team, this is the big one.
  • 10
    "Keep in mind that the only real benefit to a branch is code isolation. That means you need a concrete reason to want to have the code isolated." - How about code review? I think that's a good reason, even with only two devs. Jun 16, 2015 at 18:00
  • 2
    Code review and branching aren't really related. Are you saying you don't want code checked in to a particular branch before it's reviewed?
    – 17 of 26
    Jun 16, 2015 at 18:11
  • 5
    @17of26, yes. Code review is typically used as a prerequisite to be on the mainline. Thus you have to show the code in some way before that: on your monitor, in an email, or -- in many setups -- on a branch. This works best with a repo management tool like GitHub or gerrit. Jun 16, 2015 at 19:12
  • 3
    TFS supports code reviews through shelvesets, which are temporary holding areas in source control. Code can live there until it's reviewed and then checked in.
    – 17 of 26
    Jun 16, 2015 at 19:45
  • 2
    I guess the point is, branches aren't really the right mechanism to use for doing code reviews.
    – 17 of 26
    Jun 16, 2015 at 19:46

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team members who will try to do whatever they can not to apply your concepts.

Do they have a problem which needs to be solved? It's crucial to answer this question first, because either they actually do have a problem and will welcome your suggestions, or they are perfectly fine working as they currently do, and you are just pushing at them your way of working, just because you prefer to work this way.

Eventually, forcing them to use branches can have an extremely negative impact. Working with a trunk is easy, especially in Agile environment. A developer commits changes to the trunk, eventually handling small conflicts, and those changes are immediately used by Continuous Integration platform. With branches:

  • A developer has to think where should the change be located,

  • Somebody has to manage branches and merges from branches to the trunk,

  • Merges between branches are done less frequently than commits, which means that somebody has to deal with conflicts which are larger and more difficult to handle than a conflict between two commits,

  • Every commit doesn't find necessarily its way into Continuous Integration, which delays the information the developers get about the effects a commit can have (especially regressions).

The fact that:

The existing team are not familiar with branching

makes things even worse. I worked in a team of inexperienced programmers, where an inexperienced manager decided to play with branches. This resulted in a lot (a lot) of wasted time and is exactly the thing you want to avoid for a project which has deadlines.

  • 3
    Well in this model, how are you going to stop unstable code getting on to production without branching?
    – MrBliz
    Jun 16, 2015 at 12:34
  • 2
    @MrBliz: through switches. You can activate a feature for developers, but deactivate it for end users if it's not ready for RTM. Jun 16, 2015 at 12:36
  • 3
    Bearing in mind the experience of the developers that i'm working with, and the current lack of automated testing, i don't think that would be a good idea for our situation.
    – MrBliz
    Jun 16, 2015 at 12:41
  • 4
    @MrBliz you stop unstable code getting on to production by isolating it in release branches (that's exactly their purpose) and by testing it. Feature branches don't help in that; in fact these carry a higher risk of introducing instability by large, non-integrated, hard to control merges
    – gnat
    Jun 17, 2015 at 0:34
  • 1
    @MrBliz yeah I noticed that (and I think you got it about right, if only missed to explain the reasoning to support that). It's just that neither your comment nor this answer mention explicitly whether it's about release or feature branches (or both?), so I commented to stress the difference. FWIW being vague about this is probably the only thing that I dislike about this answer
    – gnat
    Jun 17, 2015 at 7:51

Like Mainma says, be careful with the branching. You mention branching every few weeks, is it really necessary to have a lot of branches?

Alternatively, you could also have a 'pull' model instead of a push model. If you were using Git or Mercurial, you could have an integration server validate their changes before pushing to the central server. In TFS, you can do something similar using gated check-ins. This way, you can have validation and avoid the complexity of branches.

  • Effectively there would only be three active branches(release, release candidate, and trunk) at any one time, and most of the time just the release branch, and trunk.
    – MrBliz
    Jun 16, 2015 at 12:57
  • Old branches will be deleted in TFS, or more accurately hidden.
    – MrBliz
    Jun 16, 2015 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.