Over the next week, we will be rolling out changes to how features are merged into both releases and release candidates. Going forwards, rather than using the feature promotion branch for the feature gs-pipeline/<featureName>, we will instead be using a new branch type gs-bundle-feature/<featureName>_-_<bundleId>_-_<bundleInitialEnvironment>, which you may see both in your VCS as well as on bundle conflict resolution PRs when features conflict with the bundle base branch.
​
This separate branch allows us to separate changes made when addressing merge conflicts on one environment from separate merge conflicts you may encounter when merging a feature into the bundle base branch, in turn allowing us to make improvements to the robustness of releases and release candidates going forwards.

If your pipeline's Git repository has rules set up for branch protection, status checks, CI triggers, branch cleanup, or CODEOWNERS which rely on checking branch names or contain exceptions specifically for Gearset-managed branches, you will need to add the gs-bundle-feature branch format to this exception list, to ensure we are able to add features to your releases / release candidates.
​
For example, if you have a rule set up in GitHub that restricts which branches can be created on your repo (with exceptions to allow gs-pipeline/... and other Gearset branch types), you will need to add gs-bundle-feature/... to this list.

If you do not have any branch protection rules or other branch name-dependent logic enabled for your repository, this change should not affect your team, nor any existing releases or release candidates you have already created.