Merging one change to multiple branches in Git
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Applying one fix to multiple branches is common when maintaining release lines and main development simultaneously. The safest strategy depends on whether you want full branch history or only one specific commit. This guide focuses on practical workflows using cherry-pick, merge, and branch discipline.
Choose the Right Strategy
For one isolated change, git cherry-pick is usually the best option. For a full set of commits from a feature branch, use merge or rebase workflows.
Quick decision rule:
- One commit to many branches: cherry-pick.
- Entire feature history: merge.
- History cleanup before integration: rebase then merge.
Cherry-Pick One Commit into Multiple Branches
Assume commit hash is abc1234.
This keeps changes focused and avoids unrelated commits crossing branch boundaries.
Automate Repeated Cherry-Picks
For many target branches, script the loop.
Stop on first conflict, resolve, then continue manually.
Handle Conflicts Safely
When conflicts happen:
If the branch should not receive the change:
After resolution, run tests on each branch before pushing.
Preserve Traceability with -x
Use -x when cherry-picking across maintenance branches to record source commit in message.
This improves auditability during release incident analysis.
Merge Strategy for Multiple Related Commits
If the fix spans many commits already grouped in a branch, merge may be cleaner.
Merge preserves context and avoids repeated cherry-pick conflicts across related commits.
Recommended Operational Workflow
- Create fix on one branch and open review.
- Merge or squash to primary branch.
- Backport to supported branches with cherry-pick.
- Record backport status in issue tracker.
- Run branch-specific CI before release tagging.
This keeps release management predictable and transparent.
Verify Commit Presence on Target Branches
After backporting, confirm each branch contains the intended change.
Verification is especially important when conflicts required manual edits.
Use Backport Pull Requests per Branch
For team workflows, open one pull request per target branch instead of pushing directly. This keeps CI and code review separate for each branch context.
Suggested sequence:
- Cherry-pick commit onto
backport/release-1.0. - Open pull request into
release/1.0. - Repeat for each supported branch.
This process scales better than local ad-hoc branching when maintenance windows are busy.
Keep Branch Divergence Visible
When maintaining many release branches, periodically inspect divergence so backport scope stays clear.
This highlights which commits are missing in each direction and prevents accidental omission of critical fixes.
Create a Backport Tracking Checklist
A lightweight checklist reduces missed branches during urgent fixes.
- Source commit hash recorded.
- Target branches listed.
- Cherry-pick status captured.
- CI result linked per branch.
- Release note entry updated.
Operational discipline matters as much as Git commands in multi-branch maintenance.
Common Pitfalls
- Cherry-picking dependent commits without also including prerequisites.
- Forgetting to test each target branch after backport.
- Resolving conflicts differently per branch and introducing drift.
- Losing traceability by omitting
-xin maintenance workflows. - Mixing merge and cherry-pick strategy without documented policy.
Summary
- Use cherry-pick for one change across multiple branches.
- Use merge when a full commit series should move together.
- Resolve conflicts carefully and verify each branch independently.
- Preserve provenance with
git cherry-pick -xwhen needed. - Document backports to keep release branches aligned.

