Branching Strategies [closed]

Question

The company I work for is starting to have issues with their current branching model and I was wondering what different kinds of branching strategies the community has been exposed to?

Are there any good ones for different situations? What does your company use? What are the advantages and disadvantages of them??

Answer 1

For Subversion, I agree with Ryan Duffield's comment. The chapter he refers to provides a good analyses on which system to use.

The reason I asked is that Perforce provides a completely different way to create branches from SVN or CVS. Plus, there are all the DVCSs that give it's own philosophy on branching. Your branching strategy would be dictated by which tool(s) you're using.

FYI, Svnmerge.py is a tool to assist with merging branches in SVN. It works very well as long as you use it frequently ( every 10-30 ) commits, otherwise the tool can get confused.

Answer 2

I'd highly encourage reading Eric Sink's opinion on the matter:

Chapter 7: Branches

I, like Eric, prefer the "folder" style branching that he talks about.

Answer 3

No matter which branching pattern chosen, you should try to keep your branches in a binary tree form like this:

   trunk - tags
     |
    next
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22

• Child nodes should only merge with the direct parent.
• Try ur best to merge only the whole branch with the parent branch. never merge subfolders within a branch.
• You may cherry pick commits when needed as long as you only merge and pick from whole branch.
• The next branch in the above figure is only for illustration, you may not need it.

Answer 4

1. One branch for the active development (/main or master, depending on the jargon)
2. One branch for each maintenance release -> it will receive only really small fixes, while all major development goes to /main
3. One branch for each new task: create a new branch to work on every new entry on your Bugzilla/Jira/Rally. Commit often, self document the change using inch pebble checkins, and merge it back to its "parent" branch only when it's finished and well tested.

Take a look at this http://codicesoftware.blogspot.com/2010/03/branching-strategies.html for a better explanation

Answer 5

This would depend on which Version Control System you're using. Each VCS has different approaches to branching.

Which VSC do you use?

Answer 6

Gnat has written this excellent break down on the various bits of advice your can find on branching strategies.

There's not one branching strategy, it's what works for:

• Your team size
• Your product and the lifecycle periods
• The technology you're using (web, embedded, windows apps)
• Your source control, e.g. Git, TFS, Hg

Jeff Atwood's post breaks down a lot of possibilities. Another to add is the concept of promotion (from Ryan Duffield's link). In this setup you have a dev branch, test bracnh and release branch. You promote your code up until it reaches the release branch and is deployed.