Mastership impact on release and development branches

Mastership restrictions impact how you design your release and development branching strategy.

A common branching strategy is to use a single release branch (or integration branch) and multiple development branches. The project manager or developer merges changes from the development branch to the integration branch. You can use this strategy with MultiSite, but the merges to the integration branch must occur at the replica that masters the integration branch.

Another approach is to use a single release integration branch, multiple site integration branches, and multiple developer branches. Developers or project managers at a replica merge to the site integration branch, and the project manager at the replica that masters the release integration branch merges to that branch from the site integration branches.

You may need to allow developers to transfer and request mastership of branches and branch types. Developers at different sites may have to use the same branch type (for example, because an element’s versions cannot be merged, or because each site must merge its own work to the integration branch). A branch or branch type’s mastership cannot be shared by multiple replicas; instead, there are two models for transferring mastership between replicas:

Model 1. Create a schedule that determines when each replica masters the branch or branch type. Create scripts to transfer mastership.

Model 2. Give the developers at the sites the ability to request mastership of the branch or branch type. For more information about this model, see Implementing requests for mastership.