This project is read-only.

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

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


Use Team branches to improve the integration and stabilization of breaking changes across teams.

The following is an example of what your branch structure might look like after you have created Team branches:
  • Development - Container for Team branches
    • Team 1 - Team branch
      • Source
    • Team 2 - Team branch**
      • Source
  • Main – Integration branch
    • Source
    • Other asset folders

Keep the following recommendations in mind when working with a Release branch:
  • When to branch: If your development teams’ work overlaps on files and components, use Team branches to isolate each team’s work. You might also choose to create Feature branches beneath the Team branches.
  • When not to branch: If your source tree is organized by component, and you are confident that there will not be breaking interface changes or a large number of check-in conflicts across your teams, you probably do not need team branches.
  • Permissions on branch:
    • Read/write for developers on the team.
    • Read-only for everyone else.
  • Build frequency on branch: Continuous Integration (CI) builds.
  • Testing focus on branch: Feature and quick feedback testing.

Use the Team branches to allow teams to complete development tasks in parallel. This can be useful to isolate teams from breaking changes originated by other teams, or to allow teams to work toward unique milestones. All active development should occur in the Team branches and then be integrated into the Main branch. You might also want to create Feature branches beneath each team branch.

Additional Resources

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


No comments yet.