Note: This behavior applies to most Git-based version control providers, including GitHub, Bitbucket, and GitLab. Azure DevOps and AWS CodeCommit do not automatically mark PRs as merged in the same way, so this is less likely to occur with those providers.
Sometimes you might promote a single pull request (PR) in Gearset Pipelines, and then see multiple PRs get merged with deployments happening that include changes you weren't expecting yet.
This behavior isn't unique to Gearset. It comes from how Git-based version control systems track commits and determine whether a PR has been merged.
What's happening behind the scenes in Pipelines
Pipelines uses environment branches and promotion branches to move changes safely through your pipeline.
If you're using the Expanded Branching Model, each environment in your pipeline is linked to a long-lived environment branch.
When you promote a PR, Pipelines merges a promotion branch into the target environment branch.
Each environment has a CI job that monitors the environment branch and deploys changes to its target org to keep them in sync.
So the key point is: The CI job deploys the differences between the environment branch and the last successful deployment snapshot.
How multiple PRs can merge after promoting one PR
When you promote a PR, Gearset asks your version control system to merge it into the target environment branch, respecting your branch protection rules. This can lead to unexpected deployments because:
Other PRs where all encompassing commits are shared with the promoted PR will be automatically marked as merged. This is standard Git behavior. When all of a PR's commits become reachable from the target branch, the version control system considers it merged.
The merge triggers the environment's CI job, which deploys the differences between the current environment branch and the last successful deployment. Since the branch now contains changes from all the merged PRs, the deployment may include changes you weren't expecting.
The screenshot above shows branch-3's PR (#3) on GitHub. This PR was promoted, and it contains 3 commits - two of which originated from branch-1.
The screenshot above shows branch-1's PR (#1) on GitHub. This PR was not promoted, but was automatically marked as merged because its commits were already included when branch-3's PR was merged.
Common reasons PRs share commits in a pipeline
This is most common when teams are working with:
Stacked feature branches: where a feature branch was created from another feature branch, a release branch, or any branch other than main, so multiple PRs share commits.
Cross-merging between feature branches: where changes from one feature branch are merged into another, causing them to share commit history.
The screenshot above shows a GitKraken branch graph where branch-3 was branched from branch-1, so both PRs share commits. Branch-2 also shares commits with branch-1 and would be affected. Branch-4 was branched independently and isn't affected.
We recommend always creating feature branches directly from main rather than from other feature or release branches. If you need to make changes to a user story already in progress, follow the guidance in Edit or fix a user story in progress in Pipelines.
How to confirm this is what happened
Check the environment branch history
Look at the environment branch (e.g. INT, UAT) and check which commits happened during the promotion.Compare commit lists across PRs
Check whether the PRs that merged unexpectedly share commits with the PR you promoted.Check your version control system's PR timeline
Most version control systems show when and how a PR was marked as merged. However, it may not be immediately obvious that a PR was closed indirectly due to shared commits. You may need to inspect the commit history of the environment branch to confirm this.
The screenshot above shows GitHub Desktop's view of the main branch. It confirms that commits from both branch-1 and branch-3 are now present, with the diff showing all changes combined. Branch-4's changes are not included as its PR was unaffected.
Summary
When you promote a PR in Pipelines, Gearset asks your version control system to complete the merge of the PR into the environment branch, and the environment's CI job deploys the updated branch.
If multiple PRs share commits, your version control system may mark other PRs as merged too, and those changes can be included in the deployment as part of the updated environment branch state.