This project is read-only.

How to Use Branching to Stabilize Your Development and Build Process

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

Use a Development branch for active development and a Main branch for your integration build, thus avoiding build breaks.

The following is an example of what your branch structure might look like after you have created a Development branch:
  • Development – Development Branch
    • Source
  • Main – Integration Branch
    • Source
    • Other Assets folders

Keep the following recommendations in mind when working with a Development branch:
  • When to branch – If you are creating daily builds and are having problems with build stabilization and integration, create both a Main and a Development branch to provide more predictability to your daily build. You might also want to consider more stringent check-in policies to improve check-in quality.
  • When not to branch – If you are only creating Continuous Integration (CI) builds, or your daily builds are already predictably stable, you might not need the extra overhead of an integration branch.
  • Permissions on branch:
    • The Main branch should be read/write for developers responsible for merging and integration, but read-only for everyone else.
    • The Development branch should be read/write for everyone.
  • Build frequency in branch:
    • Daily builds on the Main branch.
    • Continuous Integration builds on the Development branch.
  • Testing focus on branch:
    • Perform integration, performance, and security testing on the Main branch.
    • Perform feature and quick feedback testing on the Development branch.

Use the Main branch as a staging ground for integrating changes that have been checked into the development branch. Perform all active development in the Development branch, and integrate non-breaking changes into the Main branch.

Additional Resources

Last edited Jul 31, 2007 at 2:34 PM by prashantbansode, version 10


No comments yet.