How to Use Branching to Stabilize Development Across 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
- Team 2 - Team branch**
- Main – Integration branch
- Other Asset Folders
Keep the following recommendations in mind when you work with Team branch:
- When to branch – If your development teams overlap 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 in branch – Assign read/write permissions to developers on the team, and read-only permissions to everyone else
- Build frequency on branch – Continuous integration builds are performed on the branch.
- Testing focus in branch – Perform feature and quick feedback testing.
The Team branches should be used to allow teams to complete development tasks in parallel. This can be useful to isolate teams from breaking changes originating on 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.