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:
You can also cherry-pick a range when the commits are consecutive:
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:
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:
- Use
git restoreorgit checkoutto bring specific files from another branch. - Use
git cherry-pick -nand stage only the hunks you want.
Example with file-level selection:
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:
What happens here:
- '
git cherry-pick -napplies the commit without creating a new commit yet.' - '
git resetunstages the changes but leaves them in your working tree.' - '
git add -plets 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:
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:
Summary
- Use
git cherry-pickwhen the desired work already lives in clean commits. - Use
git restore --sourcefor file-level selection. - Use
git cherry-pick -nplusgit add -pfor 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.

