a. To allow multiple teams to work in parallel without affecting other teams' work.
b. To validate a piece of work (enhancements, bug fixes etc.) before merging into trunk (main application).
Following is excerpt from help on branching in Pega:
Because development work is typically iterative, rules are often created and modified quickly on a day-to-day basis. This rapid change can become disruptive to the overall project when this work takes place using multiple teams working in the same application RuleSets. Branches allow such development work to take place within an isolated space (the branch) without affecting functionality in the source rules.
This branching ability is especially useful on large development projects, where multiple teams work simultaneously on the rules in an application, and all members on one team need to see each others work, while also isolating their development changes from the other teams. In this way, one team's rule changes do not affect the other teams until the changes are stable, conflicts resolved, and approval granted to make the new functions available to the entire development project team.
Typically, branches are used in development environments in which multiple teams contribute to a single application. You use branches to develop software in parallel in a version-controlled environment. For example, your teams can develop one feature in a branch while another team develops a feature in a different branch, even if they share the same base rulesets. After feature development completes, you can merge the changes you made for both features into the base ruleset. You can also use branches for providing bug fixes, because you can easily add them to applications.
The major issue with branching in Pega(well not just in Pega but even more sofisticated source control systems) is the merging. Eventually you will find your selves manually merging all sorts of rules back into one version, especially on a shared rulebase where multiple applications share the same pega instance and rulebase. Therefore, except for in a prototyping environment we are not using the branching feature.
In my opinion, Branch rule-set is like a Swiss army knife, it is useful yet need to be careful with using it.
If you use it wisely, it will be a very convenient tool for managing multiple concurrent development effort, each has its own release time, however, if you are not familiar with Branch rule-set's features and their pitfalls, it may give you more headache than the relief.
Couple of headaches faced are while working with Agents and Data Pages in branches. As these rules needs access group to be mentioned in rule form, not sure whats the best way to tackle these?
In one scenario we have multiple teams having their own branches, so have to go for separate access groups which is different from trunk application. For this have to change the access group for Agent and Data Page in branch ruleset. But these rules needs to be skipped during merging (as the only change we made is access group). How to solve this issue? We have to remember this and manually delete these rules from branch just before merging? Any other better solutions?