index > Team Foundation Server - Version Control > Explanation of branching and normal workflow

Explanation of branching and normal workflow

Can someone describe more about how branching works from a developers perspective?
Or is there already information about this somewhere that I haven't found?
This would be very useful for us coming from ClearCase / Subversion / some other version control system.

What I really would like to see is an article or blogpost about how two developers working with a project/solution would do to create a branch, let one developer use this branch for a few days while the other is continuing on the normal main branch. After a few days a merge should be done.

I would like to see the steps necessary together with an explanation why this is the best way to do it if there is more than one way.

Suggested outline:
- Assume both developers has their own workspaces on their own machines
- Developer A creates a new branch of the solution (for example called 1.1-bugfix)
- Developer B makes some changes to the solution in the main branch
- Developer A makes some changes to the solution in the new branch
- Developer B merges his changes back to the main branch
- Developer B continues to work in the main branch. Might need some change to his workspace
- Developer C comes into the project and creates a new workspace connected to the new branch developer B created earlier.

Johan

Jobr77

Hello,

here are a few handy links about branching in tfs:

Regarding your solution:

it's much safer to first merge main into 1.1-bugfix branch, resolve conflicts, build, test etc. then merge it back into main; this way it's much less probable to break the main
Developer B should have both main and 1.1-bugfix enlistment on his/her local drive (2 workspaces or 1 with mappings for both Main and 1.1-bugfix); to work with solution from Main he/she open it from the local enlistment of the Main branch, when with 1.1-branch - from local enlistment of 1.1-branch

Hope this helps

Michal Malecki

Thanks!

It helped somewhat, but I haven't read it through completeley.

Jobr77

There is a lot of information out there... Also take a look at:

http://manicprogrammer.com/cs/blogs/michaelruminer/archive/2006/09/07/88.aspx

and here are some additonal good references which are by no means exhaustive:

http://www.amazon.com/gp/product/0201741172/sr=8-1/qid=1156374976/ref=pd_bbs_1/102-3771144-0916128?ie=UTF8

Streamed Lines: Branching Patterns for Parallel Software Development

Principal Consultant, Magenic -- http://blogs.manicprogrammer.com/michaelruminer

Michael Ruminer

Thanks!

I do see some information out there but seems to stumble on the same articles every time I search for "TFS" and "branching" (maybe I just need to scroll down a couple of pages).

Regarding your page it is very informative and well written, but not with all the information I wanted. I am a bit concerned how the folder structure maps to the branches in TFS. For example, in the end of the article by Brian Harry from nov 2005 (linked in a post above) he has the branches Lab21, Lab21dev, Lab22, Lab22dev, Lab23, Lab23dev and some RTM branches. To avoid that these overwrite each others file they should probably be kept in separate folders at the same level. This will pile up as a large colletion of folder below "branches". And it is a bit hard to know from the beginning how many branches there will be. What folder structure do you use for the branches part of the source tree? I'll be glad to here suggestions from anyone with some experience of TFS (or Subversion which seems to work in a similar way).

Best regard,
Johan

Jobr77

Glad you liked Brian's article. Most find it too intimidating :) Here's an overview of how we're doing things nowadays:

$/Orcas/Main
|
|----- $/Orcas/PU/CLR
|----- $/Orcas/PU/VC++
|----- $/Orcas/PU/TFS
| |
| |----- $/Orcas/feature/cool-unannounced-stuff1
| |----- $/Orcas/feature/cool-unannounced-stuff2
|
|----- $/Orcas/releases/beta1
|----- $/Orcas/releases/beta2
|----- $/Orcas/releases/RTM

"PU" stands for "product unit." These branches are the main staging point for large teams (hundreds of people) and replace the poorly-named VBLs you read about.

"Feature" is where small teams (2-15 people) do the bulk of their development & testing. As you can probably guess, there are tons of folders piling up there. Honestly, it's not a big deal. When feature crews are finished with a branch, we might re-use them for the next round of features if scalability becomes an issue (we're at something like 65M files on the server already; every new branch adds 500K-2M more). Or we might not. I don't anticipate it being a problem -- if we need more, we'll create more.

Obviously none of the Release branches exist yet...betas are a long way away, sorry! Just showing a complete view of how things will work. Hope this helps.

Richard Berg MSFT

PS here's my ongoing list of branch- and merge-related bookmarks:
http://del.icio.us/RichardBerg/branch
http://del.icio.us/RichardBerg/branchmerge

I also hope to resume blogging soon, which should get some more content out there on branch & merge scenarios in TFS specifically.

Richard Berg MSFT

Thanks!

This was more of what I wanted to see. Now I can continue to lay out our structure for some new projects.

We are currently not working with a software product as such, it's rather a customer solution but we think we will work with the solution for the same customer a year or more and there will be different releases during this time. And no, we do not have hundreds of people on this project. But we will probably do a number of projects/solutions with around 10 developers.

If anyone else has some example for smaller projects it would also be interesting.

- Johan

Jobr77

The CM Crossroads site linked above is the best general resource on branch strategies I know of. You might also look at Eric Sink's blog for examples of more typical branch usage on small/medium teams.

Richard Berg MSFT

I agree with Richard CMCrossroads is an excellent resource as is Eric Sink who is usually spot on and always pragmatic and many times just plainly succinct.

At the following URL is a tree structure I utilize http://manicprogrammer.com/cs/photos/not_blogcloggedgallery/picture169.aspx - this is from a mindmap I created and use as a guide. It differs somewhat from Richard's outline in that I place all branches such as features, releases, other purpose branches etc. under a Branches node. But it shares many of the same characteristics. A part of it is that I like to keep the mainline trunk always as pure as possible of anything but the at-this-moment mainline tip.

I tend to use a branching model that looks a lot like the model in Figure 3 of the Seapine PDF. http://downloads.seapine.com/pub/papers/SCMbranchingmodels.pdf. It's not exactly such as I don't tend to branch for QA's that I don't intend as release candidates.

I'd just provide a link to the image only but it's only appropriate to point you to the source and proper copyright respect. Not to mention the whitepaper is a good read.

Principal Consultant, Magenic -- http://blogs.manicprogrammer.com/michaelruminer

Michael Ruminer

Thanks again, both of you!

The picture was nice and I will send the link to my co-workers who wants to know more about branching.

I have started to read the CM Crossroads article Richard linked above and it seems great to, but quite long for someone who just wants a short answer (not always possible, I know). The thing I would like to add is some articles and books about SubVersion since the systems seems to work very much alike. For example this link.

http://svnbook.red-bean.com/en/1.1/ch04.html

Jobr77

I agree... I come back to that SVN redbook all the time. Good call on posting it out there. It's a great resource especially in this area of discussion.

Principal Consultant, Magenic -- http://blogs.manicprogrammer.com/michaelruminer

Michael Ruminer

reply 12