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. Going forwards, you may be unable to add features to releases or release candidates if we are unable to create these branches on your repo.
​
If you do not have any branch protection rules or other branch name-dependent logic for your repository, this change should not affect your team, or any existing releases or release candidates you have already created.