Last updated on August 7th, 2026 at 07:25 pm
The main lesson is simple: if two pull requests are dependent, combine their changes on an intermediate branch before merging once into the main branch. A deployment workflow triggered only by pushes to the main branch should then run once.
What I learned
Each merge into the main branch creates a separate push event. If two pull requests are merged into the main branch one by one, a continuous integration or deployment workflow that watches that branch will normally run twice.
The fix is to make one branch contain both sets of changes, review that combined result, and merge it into the main branch once.
How to combine dependent pull requests
- Identify the branch that should contain the final combined work, such as
feature-b. - Merge
feature-aintofeature-b. - Resolve conflicts and test the combined branch.
- Open or update one pull request from
feature-btomain. - Merge that pull request after review.
This creates one merge or push to main, so a workflow configured to run on pushes to main receives one matching event.
Why separate merges trigger separate runs
A workflow reacts to events, not to the overall intention behind several pull requests. Two merges into the watched branch are two push events. The workflow cannot assume they belong to one release unless the repository’s process groups them before that branch is updated.
Common mistakes
Problem: Both pull requests are merged directly into main.
Fix: Combine them on an intermediate branch, then merge once.
Problem: The combined branch is not tested after the first branch is merged into it.
Fix: Run the usual checks again because the interaction between the changes may introduce new failures.
Problem: A pull-request workflow still runs more than once.
Fix: Check the workflow triggers. Pull-request events can run when a pull request is opened, updated, or synchronized even when deployment on main runs only once.
Problem: Unrelated changes are forced into one pull request only to reduce workflow runs.
Fix: Keep unrelated work separate. Review clarity and release safety matter more than saving one workflow run.
Conclusion
When changes depend on each other and should ship together, combine and test them on one branch, then merge that branch into main once. The next action is to check whether the deployment workflow listens only for pushes to the main branch.