I just read through the Guide, and I'm a bit confused about the Basic plan and the role of the integration branch.
Tell me if I understood it correctly:
You have a Main branch that will always contain the latest stable changes from everywhere. So initially, you have a Main branch that you branch out into a Dev branch. At that point, you're development of features happen in the Dev branch until it reaches a
stable point, at which point you RI into the Main branch. You keep doing that until you have the features that match release 1. Once it does, you branch the Main, which will contain the stable latest features, into a Release 1 branch.
At that moment, you can continue developing new features in the dev branch, while stabilizing the Release 1 branch, until you feel it is ready to be delivered. All fixes made to the Release 1 branch must be RI into the Main branch, and FI from the Main branch
into the Dev branch. Since Release 1 has been stabilized, you change it to read-only, and package your Release 1 from the Release 1 branch. This is your first deliverable.
All the meanwhile, work is being done in the Dev branch, and being RI into the Main branch every time new stable features are made. Similarly, once enough new stable features are RI into the Main branch to meet your Release 2 feature set, you branch out Main
into a Release 2 branch, where it will be stabilized, and then made read-only once delivered to the clients.
Here I get a bit confused.
First, the basic plan talk about having 3 branch, Dev, Main and Release, yet it seems to me like basic will have a Dev, a Main and as many release branch as you have releases, am I correct to believe that here?
Second, what if 2 weeks later, we find more bugs inside Release 1. Where do I fix those bugs? Is that asking too much for Basic, to be able to fix bug in an already released branch? Is this where I am supposed to have a Service 1 branch which branches out into
a locked Release 1 branch. This way, I can keep maintaining Service 1 branch, and I can keep releasing those fixes with new locked branches from Service 1 into Release 1.1, Release 1.2, etc. ? Or I'm wrong about having one release branch per release in Basic,
and it's that the release branch actually never becomes read-only, we just keep fixing bugs over it. And once Release 2 comes out, instead of being branched form Main into Release 2, it's FI from Main into the Release branch?
This is my first confusion.
My second confusion is with the Dev branch and is kind of similar. Do I have only 1 dev branch? What if we are developing one risky feature, while also adding in small and frequent but not as risky features. Do we do it all on the Dev branch given the Basic
plan? Or do we branch the Dev branch into a Feature 1 branch, where we can work on our big feature, while using the Dev branch for the smaller feature development. In this case, would the Dev branch be like our Integration branch?
Which lead to my last confusion. Is the Dev branch the Integration branch? If it says we should use an integration branch to integrate on, so that Main remains stable and functional, is that branch our Dev branch? If not, is my Dev supposed to be a child of
the integration branch, and the integration branch a child of Main? Or are both the Integration and Dev branch a child of Main? Where does the Integration branch lies in the Basic plan?
I know this is a lot of questions at once, but I feel they all somewhat relates.
My comments are based on the Friday, August 24, 2012 version of the Branching and Merging Guide.
I recommend you re-read page 40. Most of your questions are answered there. I pasted the first part below so you can see that it answers most of your questions. Notice that it describes several variants such as :one development area vs multiple development
branches; or one release branch (reused) vs one per release. After you re-read this a couple of times. If you still have questions, let us know.
From Page 40
Basic Branch Plan
The basic branch plan with a main, dev, and release branch enables concurrent development for your next release, a stable MAIN branch for testing and a release branch for any ship blocking bug fixes.
Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.
Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting
only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch as depicted in the diagram below.
Once the release branch is created MAIN and the development branches can start taking changes approved for the next product release. An even simpler version of this plan for smaller teams might only include a MAIN and RELEASE branch. Consider this if the isolation
required only required two branches such as for smaller teams and projects.
I read over the Basic Plan again, and I understand it a lot better now. I still have two more questions.
1) Is the Branch by Feature Plan an add-on to the Basic, Standard and Advance plan? It sounds like so too me. Since the basic plan says:
Work in DEV branches can be isolated by feature, organization, or temporary collaboration.
I see this as if you isolate your DEV branches by feature, that is, you create a dev branch for each feature, you are adding the Branch by Feature plan to the basic one, no?
2) From what I understand about the Integration line pattern, it should be used whenever you are going to be RI more than one branch back into Main. So in the case of the Basic plan where I would have more than one DEV branch, I should use the Integration Line
pattern right? That means I should branch main into Integration, and Branch Integration into all of my DEV branches, am I still right?
Similarly, if I have many Release Branches, I should have an Integration branch from Main to Integration to All my Release branches?
Thank you very much for taking the time to answer me. I love this project, it is helping me a lot.
1. Yes, the technique to "Branch by feature" can be added on to any of the plans.
2. It sounds like you understand. But there are some tricky spots. It is not merely the presence of multiple dev branches that motivates the use of an integration branch. It is the fact that they must each have their code integrated and tested
before you have confidence they are stable. So if you have multiple dev branches but they are completely independent of one another, then there is not need to merge them to an integration branch first. By definition, the risk is low that one will break the
I'm not sure an integration branch makes much sense between Main and Release branches. Technically, you can do it. But release branches are used for a different purpose than development branches.
Ah, it's all starting to make a lot of sense.
So if I have 3 DEV branches, and initially, I thought they would be independent from each other, but as development progresses, I notice that DEV 1 and DEV 3 both had to heavily modify a common part of the code base, and I hadn't anticipated it, is it possible
in TFS to create the integration branch afterwards? Or is it really something that I need to anticipate from the get go to be able to use?
Thank you again.
There is a way to reparent an existing branch to an integration branch, but to do what you are asking is very tricky. The built-in reparent feature is not intended for this scenario. You may not like this solution much. If you fear this scenario,
then make your integration branch at the beginning.
So I tried an experiment. You can experiment too. Here is what I did:
I Created Dev1, Dev2, Dev3 off of Main.
Then I "decided" to create an integration branch off of Main.
I then created Dev1new and Dev3new off of Main.
I then checked out Dev1, Dev3, Dev1new, Dev3new.
I then copied the old Dev1 folder over Dev1new.
I then copied the old Dev3 folder over Dev3new.
I then checked in the Dev1new and Dev3new.
I then undid checkout on Dev1 and Dev3.
I then deleted Dev1 and Dev3 as I no longer needed them.
I created the new branching structure I desired.
I checked out every project involved in the reorganization (both old and new
Using windows explorer, I then copied the old project files over the new ones.
I verified it all worked.
I checked in the new projects (that are now off the Integration branch).
I undid checkout on the old projects as they were the source and did not get altered. The only reason I checked them out in the first place was to remove the read-only locks on them so that when they were dropped over checked out files, they would
be in the same state as the files they replaced.
As you can see, this is possible. I figured did the whole demo in 15. But it is not pretty. It is so complex that there is a risk you will make a mistake. You can also use baseless merges instead, but I am unfamiliar with them in practice and
cannot give any advice on their value.
And lets keep this in perspective. You would do all this just to reduce the risk that your Dev1 and Dev3 teams would not step on each other when they merge their changes in the common code module? The safer thing is to have a single sub-team responsible
for changing the common sub-module on behalf of both other teams. Or, you could leave Dev1, Dev2, and Dev3 branches as they are. Then, the first one(let's assume the Dev1 team) who checks in their tested code has it easy. The second team (Dev2) is responsible
for getting the latest version, merging from Main to Dev2, then ensuring all tests pass before checking it in.
If the separate projects are so different or mutually dependent on one another that they really NEED an integration branch, this should be obvious from the very beginning. And thus, you can design an integration branch from the start.
Sorry for the complicated answer. But branching cannot magically solve all problems of development. All the pieces are interrelated - the branching approach, the environments available, the way the teams are organized, the way the work is organized,
the nature of the changes made, etc...