Merging branches

After development in a branch has reached a stable state, use the Merge Branches wizard to move the branch's contents into the base rulesets. The Merge Branches wizard helps identify potential conflicts so that you can address them before moving your changes.

1. You must check in all rules into their base rulesets before you can merge them.

2. A best practice is to lock all rules after development is complete before you start the wizard. See Locking all rulesets within a branch.
3. If you want to retain a record of your branch and move branches across different development systems, you can package your branches before you start the wizard. See Packaging a branch.
4. Open the application rule for your development application that contains the branch.
5. On the Definition tab, in the Branch list, click Merge Branches. Select the branches that you want to merge and click OK. You can select all branches by clicking Select All or deselect all branches by clicking Deselect All.
6. If there are conflicts or warnings, the Target version section displays a link that opens the Conflicts and Warnings window.

You must resolve conflicts before you can merge branch rulesets.

7. The Target checked out section displays the number of rules checked out from the base ruleset (the target destination for the rules to be merged). You must check in any checked out rules before you can merge.

To see which rules are checked out and by whom, click the displayed number. In the report that opens, for each row, the Locked by column displays the operator ID of the user who has the rule checked out.

8. In the drop-down box next to the Target version section, select the base ruleset version into which rules will be merged.
Select one of the following options.

• Create New Version : Default. Select this option to create a new ruleset version in the base ruleset during the merge process, using the next highest version number that is available in the base ruleset. The default description of the to-be-created ruleset is a combination of the version number and the branch name. You can enter a new description in the field.

• An existing base ruleset version (such as 01-01-01) : You can merge rules into an existing ruleset version in the base ruleset. If the existing base ruleset version is locked, its password is required in the appropriate Number_of_passwords Password field to merge rules into that ruleset version.

As a best practice, the system administrator should be responsible for creating a new ruleset version for the base ruleset(independent of the merge wizard). Individual teams should be developing in their specific branches and then merging those branches into the existing base ruleset version created by the administrator. This process allows the administrators to have better control on versions and deliver enhancements accordingly.

9. The Number_of_passwords Passwordfield appears when you must supply a password. If you do not need to supply a password, proceed to step 10.
Select one of the following options.

• Source version: Appears when the branch ruleset version is locked. Enter the password for the branch ruleset version so that its rules can be merged. The system does not change the protection set on the ruleset version.
• Target add version: Appears when Create New Version is selected for the target and the base ruleset (the target) is password-protected for adding a new ruleset version. (This password is specified in the Security tab of the ruleset form).

Enter the password that is required for adding a ruleset version to the base ruleset. This password is specified in the To Add a RuleSet Version field on the Security tab of the base ruleset ruleform. The system does not change the protection set on the base ruleset. Entering this password allows you to create a new ruleset version in the base ruleset and to then merge the rules into this ruleset version.

• Target version: Appears when you are merging rules into an existing base ruleset version and the selected ruleset version is password protected. (This password is specified in the Versions tab of the ruleset form).

Enter the password, which was used to lock the ruleset version, for the selected ruleset version. Entering this password allows you to merge the rules into this locked ruleset version.

• Target update version: Appears when you are merging rules into an existing base ruleset version and the base ruleset (the target) is password-protected for updating a new ruleset version. (This password is specified in the Security tab of the ruleset form).

Enter the password that is required for updating a ruleset version. This password is specified in the To Update a Ruleset Version field in the Security tab of the base ruleset rule form. The system does not change the protection set on the base ruleset. Entering this password allows you to merge the rules into this ruleset version.

• Lock target after merge: Optional. Appears if Create New Version is selected or the version selected is unlocked for the target. Enter a password to lock the selected ruleset version by the merge process. At the end of the merge process, the system locks the new ruleset version using the provided password and saves it in the base ruleset.

A best practice is to enter a password to lock the new ruleset version after the merge because in the multi-team environment that typically uses branches, locking the ruleset version alerts other teams that the features in that version are complete as of the point in time the version was created.

10. Optional: Select the Keep all source rule and rulesets after merge check box to retain all the branch rulesets and the rules they contain after merging the rules into the base rulesets. By default, the system removes the branch rulesets and the rules they contain after a successful merge.
11. Click Merge to start merging the rules from the branch rulesets into the selected targets.

Open topic with navigation