Sanplex supports enhanced branch/platform management for Products, with the following key capabilities:

• Multi-branch and multi-platform management can support projects of different sizes. A Project or Execution can be linked to a specific branch or platform of a Product.
• Branches and platforms can be managed flexibly. They can be treated as concepts tied to different time phases, where different branches or platforms may be created at different stages.
• Branches and platforms support merge operations, allowing completed branches or platforms to be merged into the mainline or into other branches/platforms.
• Except for the mainline, all other branches/platforms are managed independently and cannot be mixed together.

To learn how product managers manage multi-branch and multi-platform Products in Sanplex, you can watch the video below:

（视频介绍）

The following examples use a multi-branch Product to explain the enhanced branch/platform capabilities in detail.

I. Maintain branches for a multi-branch Product

1. Set the Product as a multi-branch or multi-platform Product

When creating a Product, select Multi-Branch or Multi-Platform as the Product type.

图1

2. Manage Product branches

Go to Product > Settings > Branches to view and manage branches.

The system automatically creates a default mainline branch. The mainline cannot be edited or deleted.

图2

3. Create a branch

Click Create Branch in the upper-right corner of the branch list to open the branch creation dialog.

Enter the branch name and description, then click Save.

图3

4. Edit a branch

Click Edit in the branch list to modify a branch.

You can update the branch name, branch status, and branch description.

After a branch is created, its default status is Active. You can later change it to Closed.

图4

To edit multiple branches at once, select several branches and click Edit at the bottom of the page to open the batch edit page.

图5

Batch edit page:

图6

5. Close a branch

You can close a branch using the Close action in the action column on the right side of the branch list.

图7

6. Merge branches

The mainline cannot be merged. If the mainline is selected in the branch list along with other branches, the Merge button is not displayed at the bottom.

图8

When only non-mainline branches are selected, the Merge button is displayed.

图9

After clicking Merge, the selected branches can be merged into another existing branch that is not selected.

When branches are merged, their related Releases, Plans, Versions, Modules, Requirements, Bugs, and Test Cases are also merged into the target branch.

图10

Branches can also be merged into a newly created branch.

Select Create New Branch, enter the new branch name and description, then click Save to merge into the new branch.

图11

After you click Save, the system asks for confirmation. Branch merge operations cannot be undone, so proceed with caution.

图12

II. Maintain modules for each branch

After branches are set up, the next step is to maintain modules under each branch. Module maintenance for branches works the same way as module maintenance for a standard Product.

1. Add modules for a branch

Go to Product > Settings > Modules to create and manage modules under the current branch.

图13

After switching the branch in the Product selector, you can create modules for other branches.

图14

2. Display settings for module names and branch names

In multi-branch Products, Display Settings includes an additional option to show branch names.

Click Display Settings under Modules to control whether the list displays module names and branch names.

图15

If both are enabled, the requirements list appears as follows:

图16

III. Other branch-related functions and logic

You can associate branches with Requirements, Modules, Plans, and Releases.

You can also associate branches with Versions, Bugs, and Test Cases.

Projects and Executions can be linked to Product branches for requirement delivery and development.

1. Module display and selection logic

• When creating or editing a Requirement, Bug, or Test Case under the mainline, only modules from the mainline can be selected.
• When creating or editing a Requirement, Bug, or Test Case under Branch 1, modules from Branch 1 and the mainline can be selected.
• For upgraded data, if a Requirement, Bug, or Test Case belongs to a module under a specific branch, it will be assigned to the branch that owns that module after the upgrade.

Using Requirements as an example:

• When creating a Requirement in the mainline, only mainline modules can be selected.
• After switching to a non-mainline branch, the Module field allows you to select modules from both the current branch and the mainline.

图17

2. Plan display and selection logic

• When creating a Requirement and linking it to a Plan, only non-parent Plans in the current branch that have not expired can be selected.
• When a Plan is linked to Requirements, a mainline Plan can link only to mainline Requirements.
• When a Plan in Branch 1 is linked to Requirements, it can link to both mainline Requirements and Branch 1 Requirements.
• When creating a Project or Execution, only non-parent Plans in the branch that have not expired can be linked.
• When editing a Project or Execution, any non-parent Plan in the branch can be linked.

3. Logic for linking Requirements and Bugs to Versions

• When linking Requirements to a mainline Version, the list initially shows mainline Requirements already linked to the Execution but not yet linked to the Version. After clicking Search, all mainline Requirements are shown.
• When linking Bugs to a mainline Version, the list initially shows mainline Bugs under the Execution that are not yet linked to the Version. After clicking Search, all mainline Bugs are shown. (The Execution linked when the Bug was submitted is no longer used as a separate distinction.)
• When linking Requirements to a Branch 1 Version, the list initially shows Requirements from the mainline and Branch 1 that are already linked to the Execution but not yet linked to the Version. After clicking Search, all Requirements from the mainline and Branch 1 are shown.
• When linking Bugs to a Branch 1 Version, the list initially shows Bugs under Branch 1 in the Execution that are not yet linked to the Version. After clicking Search, all Bugs from the mainline and Branch 1 are shown.

Using Version > Link Requirements as an example:

• On the page for linking Requirements to a mainline Version, before clicking Search, the list shows mainline Requirements that are already linked to the Execution and not yet linked to the Version.
• After clicking Search, all Requirements under the mainline are displayed.

图18

4. Logic for linking Requirements and Bugs to Releases

4.1 Link Requirements and Bugs to a Product Release (mainline)

• Link Requirements: By default, only mainline Requirements of the current Product are shown. Search results also show only mainline Requirements.
• Link Bugs: By default, only mainline Bugs of the current Product are shown. Search results also show only mainline Bugs.

4.2 Link Requirements and Bugs to a Product Release (Branch 1)

• Link Requirements: By default, Requirements from Branch 1 and the mainline of the current Product are shown. Search results also include Requirements from Branch 1 and the mainline.
• Link Bugs: By default, Bugs from Branch 1 and the mainline of the current Product are shown. Search results also include Bugs from Branch 1 and the mainline.

4.3 Link Requirements and Bugs to a Project Release (mainline)

• Link Requirements: By default, the list shows mainline Requirements linked to the Product associated with the Version. Search results show all mainline Requirements under the current Product.
• Link Bugs: By default, the list shows mainline Bugs linked to the Product associated with the Version. Search results show all mainline Bugs under the current Product.

4.4 Link Requirements and Bugs to a Project Release (Branch 1)

• Link Requirements: By default, the list shows mainline and Branch 1 Requirements linked to the Product associated with the Version. Search results show all mainline and Branch 1 Requirements under the current Product.
• Link Bugs: By default, the list shows mainline and Branch 1 Bugs linked to the Product associated with the Version. Search results show all mainline and Branch 1 Bugs under the current Product.

4.5 Default scope when linking legacy Bugs

By default, the list includes unlinked Bugs that belong to the current Product’s branch or mainline for the current Release, where the Bug creation date falls within the start and end dates of the iteration linked to the Version (inclusive), and the Bug is either in Active status or has a resolution date later than the end date of the Execution linked to the Version.

4.6 Default scope when linking resolved Bugs

By default, the list includes unlinked Bugs that belong to the current Product’s branch or mainline for the current Release, where the Bug resolution date is later than the start date of the iteration linked to the Version and the Bug belongs to the Execution linked to the current Version, or does not belong to that Execution but has a creation date earlier than the start date of the Execution linked to the Version.