Team Foundation Server (TFS)

• TFS Server
• TFS Client (VS,browser)

Branching and merging 

TFS branching and merging : https://msdn.microsoft.com/en-us/library/bb668955.aspx

Copied from http://blog.tfsserver.com/a-straightforward-guide-to-branching/

My general recommendation is up to 3 branches:

• The Main Line – This is what gets deployed
• A Quality Branch (optional) – Typically known as the Dev line
• Production Support Branch (optional) – Needed when production breaks so often that we know we’re going to need an emergency fix in the middle of our sprint.

Do NOT Branch by Version

I see this all the time. Every time a team releases a new version of their build to production they spin off a new branch. When I audit these scenarios I’ll see something that looks a lot like this:

My first question is always, “When’s the last time anyone used Version 1.0?” If the answer is anything other than within the last week, I know we have a code organization problem. If you want to snapshot your code during a deployment, add a label. You don’t need a branch.

The Main Line

Everybody has a Main line, even if they didn’t call it that. This is where code that is going to be deployed resides. For many teams, this may be all you need. Your developers work in the Main line, they deploy from the Main line. What’s more simple than that?

If you only have a Main line, don’t be embarrassed or ashamed. It doesn’t mean you’ve done anything wrong. The Main line is efficient. It means you’re verifying your code works before you check it in. It means that your code is good enough that you don’t need to worry about having to support an emergency deployment. You know you can branch by label if an emergency happens, otherwise you’ll just solve the problem during your next release.

If you’re just starting on a project and you have a small team of close developers. This is where you should begin. Don’t add layers until you need to.

The Dev Line

One day you may decide that Main is just too precious. We need to protect Main from those other nasty developers. So you’ll decide to add a Dev line. This is what I call branching for quality.

When you branch for quality, you make all the changes in your Dev line. You want developers to check in early and often to avoid merge issues, but you also want to provide an additional quality gate before it makes it into the Main line. A few examples of such quality gates:

• Code Reviews
• Unit Testing
• Gated Check In or Continuous Integration Builds

This model is especially useful for contractors and vendor based development teams. By locking down your Main line and having the contractors work in the Dev line, it provides you an opportunity to review any code and ensure it passes your quality gates before making it into the Main line. Merging is extremely simple, as you’re only doing a one way merge from Dev into Main. No conflicts necessary.

The Release Line

If you often find yourself working on emergency break fixes outside of your normal release schedule, instead of creating a branch for each release, create a single Release branch. This code should always be what exists in production today. By having a single Release branch, merging stays simple and there’s never any confusion as to what code is live.

Day to day, your developers would still work in either your Dev or Main line. When you release to prod, you’ll do a merge from Main into Release, and hopefully it won’t need to be used. But if that day comes when you need to fix something and fast, the Release line will be there for you. Make the fix in the release line, test it, deploy it, and save the day. After you pulse returns to normal, merge the fix into Main and if necessary from Main into Dev.

Working in your Release line should not be common. If you’re in there more than a day or two, you’re probably not fixing a bug, you’re adding a new feature. I’ve seen projects where the client agreed to one thing in the sprint. You start working on the sprint, you’re two weeks in and now the client wants a new feature and he wants it now. The problem, you still have 2+ weeks left. So should you just create the feature in your Release line? NO! If your client can’t go two weeks without deciding he needs something else, then you don’t need more branches, you need shorter sprints.

Check In Early, Check In Often

The best way to avoid merge conflicts is to have developers check in their code as often as possible. Not only will this avoid merge issues down the road, but it keeps your code safe, which is a large reason you’re using source control in the first place. The longer a developer goes without checking in code, the more work and more money that’s wasted if something were to happen to their system. I’ve seen a developer leave a company who hadn’t checked in their code in a week, basically throwing away a week’s worth of work.

I recommend checking in at the end of each task and at the end of each day. You should never lose more than a days worth of work. If the code you’re working on at the end of the day would destroy the build, use shelving. Shelving is basically a private check in. The code is stored on the server, but it is unique to you. No worries about breaking the build, no worries about losing your work. Win-Win!