This project is read-only.

How to Plan Your Branching Structure

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode

Branches are a mechanism to enable isolation; they are used to allow multiple developers to work on the same files in isolation. To plan your branching approach, evaluate common branching scenarios and choose a strategy based on team size, composition, release schedule, and build stability requirements.

Common branch scenarios include:
  • Release – Branch to stabilize code you want to release. You can branch before release, avoiding the need to lock down the main branch.
  • Maintenance – Branch to maintain a previously released build.
  • Feature – Branch to isolate feature development that might make the rest of the project unstable.
  • Team – Branch to isolate sub-teams so that they can work without being subject to breaking changes, or that they can work towards unique milestones. These are very similar to feature branches.

Do not branch unless it becomes necessary for your development team. Branching introduces additional source tree maintenance and merging tasks. Most development teams working on short release cycles (e.g., Line-of-Business LOB applications) will never need a branch. Development teams working on longer release cycles (e.g., packaged Independent Software Vendor ISV applications) are more likely to employ branching as part of the development process.

Additional Resources

Last edited Jul 31, 2007 at 2:30 PM by prashantbansode, version 12


No comments yet.