Git
Partial Merge
Branch Management
Version Control
Software Development

git partial merge, not whole branch

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Git does not have a special "partial merge" command that merges only the nice parts of a branch and ignores the rest. In practice, a partial merge means selecting specific commits or selected file changes and applying them to another branch in a controlled way.

The Usual Answer: Cherry-Pick Specific Commits

If the work you want is already separated into clean commits, git cherry-pick is the most direct solution. It copies chosen commits onto the current branch without merging the full branch history.

Suppose feature contains five commits, but you only want two bug fixes on main:

bash
git switch main
git cherry-pick a1b2c3d
git cherry-pick d4e5f6g

You can also cherry-pick a range when the commits are consecutive:

bash
git switch main
git cherry-pick start_commit^..end_commit

This is usually the cleanest workflow because Git records exactly which commits were applied.

When the Source Branch Is Messy

Sometimes the branch contains incomplete work mixed with the changes you want. In that case, first identify the exact commits:

bash
git log --oneline feature

If the needed changes are not isolated into separate commits, partial merge becomes a patch-selection problem instead of a history-selection problem. Then you have two common options:

  1. Use git restore or git checkout to bring specific files from another branch.
  2. Use git cherry-pick -n and stage only the hunks you want.

Example with file-level selection:

bash
git switch main
git restore --source feature -- app/config.yml src/auth.js
git commit -m "Bring auth and config changes from feature"

That does not preserve the original commit boundaries, but it is practical when only certain files are ready.

Partial Changes Inside One File

If only part of a file should move over, use interactive staging. One reliable workflow is:

bash
1git switch main
2git cherry-pick -n a1b2c3d
3git reset
4git add -p
5git commit -m "Apply selected hunks from feature commit"

What happens here:

  • 'git cherry-pick -n applies the commit without creating a new commit yet.'
  • 'git reset unstages the changes but leaves them in your working tree.'
  • 'git add -p lets you choose which hunks to stage.'

This is more manual, but it gives precise control.

Why Not Use a Real Merge

A normal git merge feature says "bring the branch history together." If you only want a subset of the work, a full merge is the wrong tool because it records that all branch history is now integrated.

That matters later. Git may think the branch has already been merged even though only some changes were actually adopted. Cherry-picking and patch-based workflows avoid that misleading history.

Conflict Handling

Partial merges still produce conflicts when selected changes depend on code that was not brought over. That is the hidden cost of this approach: commits are not always independent just because they look small.

A good habit is to inspect the dependency chain before cherry-picking:

bash
git show --stat a1b2c3d
git log --oneline --graph --decorate feature

If commit B assumes code introduced in commit A, take both or rewrite the result carefully after conflict resolution.

Common Pitfalls

The biggest mistake is using partial merge as a substitute for disciplined commits. If a branch constantly requires selective extraction, the real issue is usually that unrelated work is being bundled together.

Another mistake is cherry-picking merge commits without understanding their parents. That can work, but it is much trickier than picking a normal commit and often pulls in context you did not intend.

A third problem is losing traceability. If your team relies on issue-linked commits, mention the original commit hash in the new commit message so others can find the source:

text
Cherry-picked from a1b2c3d

Summary

  • Use git cherry-pick when the desired work already lives in clean commits.
  • Use git restore --source for file-level selection.
  • Use git cherry-pick -n plus git add -p for hunk-level control.
  • Avoid full merges when you only want part of a branch.
  • If partial merges are common, improve commit hygiene so features are easier to extract.

Course illustration
Course illustration

All Rights Reserved.