In branching, developers work on private branches to isolate their code from other developers and merge changes back to the main branch.

Different strategies can be followed, depending on the size of the development team.

In the Simple Development Model, all development occurs on a single main branch. This strategy has the following characteristics:

• Only for emergency fixes

• Checkouts might not be the most current code

• Carries a stability risk for the mainline branch

The figure shows the Simple Development Model.

In the Small Team Development Model, development occurs on a single Dev branch, with a separate Main branch strictly for releases. This strategy has the following characteristics:

• The Mainline is the official release branch

• Development occurs on a separate branch

• Stable code is merged back to Main at key milestones

• Branches are synchronized periodically

The figure shows the Small Team Development Model.

In the Multi-Team, Multi-Release Model, development occurs on multiple Dev branches, again with a separate Main branch strictly for releases. This strategy has the following characteristics:

• Supports more efficiency over disparate teams

• Development occurs on separate branches

• Stable code is merged back to Main at key milestones

• Branches are synchronized periodically

The figure shows the Multi-Team, Multi-Release Model.

Using complex branching strategies requires attentive organization of repository files, as well as altering the Multiuser setting in the Administration Tool.

1. Create a Main repository (Master Repository) and store it in the Master multiuser development directory.

   • Projects must be explicitly defined.

   • Branch developers shouldn't have access to the Master directory.

2. Create a subset of branch repositories by extracting from Main and storing them as the Team1 and Team2 multiuser development directories. The Main and Team RPDs must be stored and secured in separate directories on the network.
3. Developers must check out, develop, merge, and publish from their respective Team RPDs. Developers A1 through A3 and B1 through B3 should manage their metadata work and merge to their Team repository.

   • Teams 1 and 2 must maintain their own repositories and periodically synchronize from Main to Team branches.

   • The Team repositories must be merged back into and published in the Main repository.

4. One specific group, for example, release management, should manage all project definitions, perform merges, publish, and synchronize the Team RPDs back to Main.

For large development teams, it's a good practice to perform periodic branch synchronization as Main changes, in order to ease the ultimate Team publishing step.

1. Publish all changes from your Team development branch and open the Oracle BI repository (RPD) in the Administration Tool. This the current repository.
2. Extract a fresh Branch subset from Main. This is the modified repository.
3. In the Administration Tool, select File, then select Merge and browse to the backup of the previous Branch subset. This is the original repository.
4. Resolve all issues and perform the merge.

   The repository named in the Save merged repository as field becomes the new branch development Oracle BI repository and is called the Original in future synchronizations.