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

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

Answer 2

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.

Answer 3

Henrik Kniberg's Version Control for Multiple Agile Teams also has some good points to take into consideration.

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

Answer 5

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.

Answer 6

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.