Git
version control
branching
merge
software development

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.

bash
1git checkout release/1.0
2git cherry-pick abc1234
3
4git checkout release/1.1
5git cherry-pick abc1234
6
7git checkout main
8git cherry-pick abc1234

This keeps changes focused and avoids unrelated commits crossing branch boundaries.

Automate Repeated Cherry-Picks

For many target branches, script the loop.

bash
1commit=abc1234
2for branch in release/1.0 release/1.1 main; do
3  git checkout "$branch"
4  git cherry-pick "$commit" || break
5done

Stop on first conflict, resolve, then continue manually.

Handle Conflicts Safely

When conflicts happen:

bash
# resolve files manually
git add <resolved-files>
git cherry-pick --continue

If the branch should not receive the change:

bash
git cherry-pick --abort

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.

bash
git cherry-pick -x abc1234

This improves auditability during release incident analysis.

If the fix spans many commits already grouped in a branch, merge may be cleaner.

bash
git checkout release/1.1
git merge bugfix/payment-timeout

Merge preserves context and avoids repeated cherry-pick conflicts across related commits.

  • 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.

bash
1git checkout release/1.0
2git log --oneline --decorate --grep "fix timeout"
3
4git branch --contains abc1234

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.

bash
git checkout main
git log --oneline release/1.0..main
git log --oneline main..release/1.0

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 -x in 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 -x when needed.
  • Document backports to keep release branches aligned.

Course illustration
Course illustration

All Rights Reserved.