There is always a lot of discussion about branching philosophies. From what I've found, there is no one right answer. That being said, there are better approaches than others.
We do things pretty consistent across our development groups so I thought we'd share it with you here. It is in my opinion, this approach is the best branching approach for developing and supporting multiple releases based off of one code base.
What we do is a variation of what they call the "Hybrid Branching Structure" in Microsoft's Live Meeting called "Application Platform: Branching and Merging: Which Approach Is Right for You (Level 200)"
First we have a mainline for each Application. Some people may call this "main" but we refer to it as mainline. Mainline is wide open for all developers working on that Application.
$/TeamProject
/App
/mainline
Then when we do code freeze, we branch the mainline to a folder under releases to it's appropriate major.minor release number. Release branches are read-only for everyone. If a change (either a Bug fix or Enhancement) is needed, permissions are opened for that one user after the Release Manager gives approval. Once the change is made, permissions are removed.
$/TeamProject
/App
/mainline
/releases
/releaseX.X (* branched from mainline)
For an application that has been around for a while and had a number of releases, the TFS structure looks something like this. In this example, we release every month and use year.month for our major.minor release numbers.
$/TeamProject
/App
/mainline
/releases
/release8.1 (* branched from mainline)
/release8.2 (* branched from mainline)
/release8.3 (* branched from mainline)
/release8.4 (* branched from mainline)
This approach seems to be the best for us. It minimizes the need for merging and allows us to support multiple releases at once.
UPDATE: There have been some questions about how we merge using the branch philosophy stated above. When a change is made to a release branch, that change is merged back to the mainline. Depending on how many "live" branches you're supporting, you may (or may not) have to merge it into other branches as well. For example, if you made a change to release8.3, it should be merged into mainline AND release8.4.
Thursday, January 17, 2008
How we branch our code in TFS
Subscribe to:
Post Comments (Atom)
11 comments:
Hi,
Lets say that I have 2 releases (Release1.0 and Release2.0).
If I have made bug fixes in Release1.0, how do you merge from Release1.0 to Release2.0. I can only merge Release1.0 into "Mainline" and not to Release2.0. I can only see my "Mainline" in the drop down "Target branch". Any suggestions?
Thanx.
/Dennis Johansson, Itmaskinen AB
Hey Dennis! What we do is go from Release 1.0 to mainline to Release 2.0.
In my example, directly going from Release 1.0 to Release 2.0 is not possible. Though for us, that is not a big deal as we typically make the change on the mainline first. Then merge it up.
If that does not work for you, then you can go from Release 1.0 to mainline and then back up to Release 2.0.
And if that does not work, I think there is the concept of a baseless merge, but I've not looked into it much.
Of course, you can always just manually make the changes, but that often becomes laborious if you have a number of changes.
Hope that helps.
The branching idea seems to be fair enough..but i have a scenario where some of the developers start coding on next release, where other developers remain to work on current release. Then, in that case all the developers cannot use "MainLine" for checking in their code right?..how do we solve this issue in TFS
murail, what I would do is branch off the release for "release" developers and then require them to merge their changes back to the mainline after they are done with the release feature.
Actually, I would merge back every few days to the two branches don't deviate too far from each other.
I am now setting up our project branching structure in 2010 beta 2 and am proposing something similar:
$/TeamProj/APP/DEV (for mainline development)
$/TeamProj/APP/PRE-ALPHA (contains branches of DEV for release hardening)
$/TeamProj/APP/REL (contains branches of DEV which are releases)
I do not want any development under REL whatsoever. When a branch is created under REL I'd like it to be read only. I'd like this to happen automatically. It seems that the permissions of the new branch are inherited from the parent branch (not REL folder).
How can I (easily) automate this?
Hello My dear Friend i m new here in your blog and i m expecting more from you ...
I m a fresher with TFS ?
First of all
Can you please tell me about the TFS?
What is this ?
When we have to use this ?
where we can use this ?
How can we use this ?
All the above question running in my mind can you please help me out.
I attempted to provide a training video describing some of the concepts behind effective branching and merging by using Microsoft's guidance from the ALM Rangers and the Patterns & Practices teams. Hopefully it will help.
http://blogs.us.sogeti.com/ericswanson/2010/09/07/effective-branching-and-merging-in-tfs-2010/
3 Questions:
If we have Main, 1.0, 2.0 branches, why do we branch 2.0 from Main. Why can't we branch 2.0 from 1.0?
If we branch 2.0 from 1.0, will we be able to merge from 1.0 to 2.0 directly or do we still need to go through the Main (1.0 -> Main -> 2.0)
Is there a way to do automerge in TFS 2010?
Hi Dusty. You can branch 2.0 from the 1.0 branch. I guess the main goal is to isolate your code-lines so you can work on the next major release (2.0) and fix bugs or apply service packs to previously released software (1.0). For us, our next major release is done on the mainline. We then branch (e.g. 2.0) from the mainline when the code freeze happens. We then work on those branches when fixes are needed.
If you branch 2.0 from 1.0, you can go direct to the 2.0 branch. In this case, the mainline becomes dead in my mind. Or maybe you use it for POC things.
By "automerge" do you mean a Wizard to help you do the merge? If so, then yes there is a nice wizard feature. I use it all the time and 90% of the time, it does the full merge for me. All I have to do is click a few buttons. Works slick.
Hope this helps.
What a clear, precise and nice post there. Much appreciated!
Hi, I have the following question?
I have a feature branch, branched off from mainline. The branch is kept in sync with the changes on mainline. This is done by merging and merge conflicts had to be resolved. Now the feature is ready and I want to reintegrate the branch back to mainline, but I don't want to resolve the merge conflicts again. Does TFS provide a solution for that?
Post a Comment