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??

Alcoholometer

Read this classic: oreilly.com/catalog/practicalperforce/chapter/ch07.pdf – Uttermost

Answer 1

Here is the method I've used in the past with good success:

/trunk - bleeding edge. Next major release of the code. May or may not work at any given time.

/branches/1.0, 1.1, etc. Stable maintenance branches of the code. Used to fix bugs, stabilize new releases. If a maintenance branch, it should compile (if applicable) and be ready for QA/shipping at any given time. If a stabilization branch, it should compile and be feature complete. No new features should be added, no refactoring, and no code cleanups. You can add a pre- prefix to indicate stabilization branches vs maintenance branches.

/branches/cool_feature. Used for highly experimental or destructive work that may or may not make it into trunk (or a maintenance branch). No guarantees about code compiling, working, or otherwise behaving sanely. Should last the minimum time as possible before merging into the mainline branch.

/tags/1.0.1, 1.0.2, 1.1.3a, etc. Used for tagging a packaged & shipped release. Never EVER changes. Make as many tags as you want, but they're immutable.

Persons

In your branches/cool_feature folders, do you branch the whole trunk or just certain sub-folders? – Farmyard

typically it's the whole trunk. rarely does a feature only touch one directory. i also highly recommend svnmerge.py if you aren't running svn 1.5. makes the whole branch/merge process much nicer. – Persons

You present a very good well though out model. A policy that my company enforces, and I think this is fairly common, is that the trunk should always build and pass all test. So you say under your model that it 'may or may not work'. There are varying degrees of stabilization, and I think that enforcing the rule that the trunk should always build and automated tests should always pass is a good rule in general. – Guile

If you use branches to "stabilize new releases", then how do you (continuously) build and (automatically) test it? For me what is essential about trunk is that it is the version that is (continuously) build and (automatically) tested after each commit. I think one should stabilize a release within a trunk and use branches for both future and past versions, whereas trunk should be for the current. And if it is possible to (continously) build and (automatically) test all the branches, then trunk is not needed at all. Am I right? – Romanic

Answer 2

Our repository looks like:

/trunk
/branches
/sandbox
/vendor
/ccnet

/trunk is your standard, bleeding edge development. We use CI so this must always build and pass tests.

/branches this is where we put 'sanctioned' large changes, ie something we KNOW will make it into trunk but may need some work and would break CI. Also where we work on maintenance releases, which have their own CI projects.

/sandbox each developer has their own sandbox, plus a shared sandbox. This is for things like "Lets add a LINQ provider to our product" type of tasks that you do when you are not doing your real work. It may eventually go into trunk, it may not, but it is there and under version control. No CI here.

/vendor standard vendor branch for projects where we compile but it is not code that we maintain.

/ccnet this is our CI tags, only the CI server can write in here. Hindsight would have told us to rename this to something more generic such as CI, BUILDS, etc.

Canicular

Answer 3

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

Ketone

Answer 4

The first thing: KISS (Keep it simple stupid!)

/branches
  /RB-1.0 (*1)
  /RB-1.1 (*1)
  /RB-2.0 (*1)
/tags
  /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2)
  /REL-1.1
  /REL-2.0
/trunk
  current development with cool new features ;-)

*1) Keep version maintainable - e.g. Service Packs, Hotfixes, Bugfixes which may be merged to trunk if necessary and/or needed) *2) major.minor.build.revision

Rules of the thumb:

1. The Tags folder need not to be checked out
2. Only few coding in release branches (makes merging simpler) - no code cleanup etc.
3. Never to coding in tags folder
4. Never put concrete version information into source files. Use Place-holders or 0.0.0.0 which the build mechanism will replace by the version number you're building
5. Never put third party libraries into your source control (also no one will add STL, MFC etc. libraries to SVN ;-))
6. Only commit code that compiles
7. Prefer using environment variables instead of hard-coded paths (absolute and relative paths)

--hfrmobile

Propinquity

Answer 5

We branch when a release is ready for final QA. If any issues are discovered during the QA process, the bugs are fixed in the branch, validated and then merged to the trunk. Once the branch passes QA we tag it as a release. Any hotfixes for that release are also done to the branch, validated, merged to the trunk and then tagged as a separate release.

The folder structure would look like this (1 QA line, 2 hotfix releases, and the trunk):

/branches

/REL-1.0

/tags

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/trunk

Primatology

Answer 6

We use the wild, wild, west style of git-branches. We have some branches that have well-known names defined by convention, but in our case, tags are actually more important for us to meet our corporate process policy requirements.

I saw below that you use Subversion, so I'm thinking you probably should check out the section on branching in the Subversion Book. Specifically, look at the "repository layout" section in Branch Maintenance and Common Branch Patterns.

Hopping

Answer 7

The alternative I'm not seeing here is a "Branch on Change" philosophy.

Instead of having your trunk the "Wild West", what if the trunk is the "Current Release"? This works well when there is only one version of the application released at a time - such as a web site. When a new feature or bug fix is necessary a branch is made to hold that change. Often this allows the fixes to be migrated to release individually and prevents your cowboy coders from accidentally adding a feature to release that you didn't intend. (Often it's a backdoor - "Just for development/testing")

The pointers from Ben Collins are quite useful in determining what style would work well for your situation.

Abbreviate

We used to have this model, but the constant merging back of changes from the branches turned out to be prohibitively complex. Now we use trunk for bleeding edge, and branches for stabilization and maintenance. This way no merging of trees is needed. – Barbitone

Answer 8

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.

Brachio

Answer 9

We currently have one branch for ongoing maintenance, one branch for "new initiatives" which just means "stuff that will come out sometime in the future; we're not sure when." We have also occasionally had two maintenance branches going on: one to provide fixes for what is currently in production and one that is still in QA.

The main advantage we've seen is the ability to react to user requests and emergencies more rapidly. We can do the fix on the branch that is in production and release it without releasing anything extra that may have already been checked in.

The main disadvantage is that we end up doing a lot of merging between branches, which increases the chance that something will get missed or merged incorrectly. So far, that hasn't been a problem, but it is definitely something to keep in mind.

Before we instituted this policy, we generally did all development in the trunk and only branched when we released code. We then did fixes against that branch as needed. It was simpler, but not as flexible.

Charis

Answer 10

The philosophy that we follow at work is to keep the trunk in a state where you can push at any time without drastic harm to the site. This is not to say that the trunk will always be in a perfect state. There will of course be bugs in it. But the point is to never, ever leave it broken drastically.

If you have a feature to add, branch. A design change, branch. There have been so many times where I thought, "oh I can just do this in the trunk it isn't going to take that long", and then 5 hours later when I can't figure out the bug that is breaking things I really wished that I had branched.

When you keep the trunk clean you allow the opportunity to quickly apply and push out bug fixes. You don't have to worry about the broken code you have that you conveniently branched off.

Volition

Answer 11

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.

Karalee

Answer 12

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.

Stevie