This project is read-only.

Question: How do I use branching to reduce conflicts between features?

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


Use Feature branches to improve the integration and stabilization of breaking changes across features.

The following is an example of what your branch structure might look like after you have created Feature branches:
  • Development – Container for Feature branches
    • Feature A – Feature branch
      • Source
    • Feature B – Feature branch
      • Source
    • Feature C – Feature branch
      • Source
  • Main – Integration branch
    • Source
    • Other asset folders

Keep the following recommendations in mind when working with Release branches:
  • When to branch: Feature teams often have source file overlap, thereby increasing the potential for build breaks and check-in conflicts. If you are experiencing these types of problems, consider feature branches for each feature to provide feature isolation. You can create these off a Main branch for small teams, or off Team branches for larger teams.
  • When not to branch: If you are only creating CI builds, or your daily builds are already predictably stable, you might not need the extra overhead of feature branches.
  • Permissions on branch:
    • Read/write permissions for developers on the Feature branch.
    • Read-only for everyone else.
  • Build frequency on branch: CI builds.
  • Testing focus on branch: Feature and quick feedback testing.

Use Feature branches to allow each feature to be developed in parallel. Perform all active development on the Feature branches and then integrate your code into the Main branch.

Additional Resources

Last edited Jul 18, 2007 at 11:10 PM by jtaylorsi, version 6


No comments yet.