Git Merge vs. Git Rebase vs. Git Cherry-Pick

If you use Git, you might wonder which command is best for combining changes. Here is a simple explanation and a practical guide to choose the right one.

Quick definitions

• git merge — Combines two branches by creating a merge commit. It keeps the full history of both branches.
• git rebase — Moves commits from one branch on top of another, rewriting history to make it linear.
• git cherry-pick — Copies one or more specific commits from one branch onto another without merging everything.

Mental model:

• Merge = "Bring history together with a new node"
• Rebase = "Replay my commits elsewhere to create a straight line"
• Cherry-pick = "Pick only these commits, not the whole branch"

How they work (commands)

Merge the feature into main and keep the real history:

git checkout main
git merge feature/login

Rebase the feature onto main to make a linear history:

git checkout feature/login
git rebase main

# If conflicts appear, fix files, then
git add .
git rebase --continue

Cherry-pick a specific commit (by hash) into the current branch:

git checkout release/1.2
git cherry-pick a1b2c3d

Cherry-pick a range of commits (start..end, end is exclusive):

git cherry-pick a1b2c3d..f6e7d8c

When to use which

• Use merge when:

  • You want to preserve the full history and context of work.
  • You are integrating a completed feature via Pull Request.
  • The team prefers non-rewritten history (common on large teams).

• Use rebase when:

  • You want a clean, linear history in your feature branch before opening a PR.
  • You are syncing your branch with the latest main without adding merge commits.
  • You are working solo or rebasing a branch that no one else has pulled.

• Use cherry-pick when:

  • You need one (or a few) specific fixes on a release branch.
  • You want to hotfix production without merging unrelated changes.
  • You are backporting a bug fix to an older version.

Pros and cons

Merge:

• Pros: preserves history and context; safer for shared branches; easy to review.
• Cons: more merge commits; history can look "busy".

Rebase:

• Pros: linear, clean history; easier to follow blame and bisect.
• Cons: rewrites history; dangerous on shared branches; requires careful conflict resolution.

Cherry-pick:

• Pros: very targeted; perfect for hotfixes and backports.
• Cons: can duplicate commits across branches; excessive use can fragment history.

Practical examples

Sync your feature with main (preferred before opening a PR):

git checkout feature/payments
git fetch origin
git rebase origin/main

Resolve conflicts safely during rebase:

# After fixing conflicts in files
git add path/to/conflicted-file
git rebase --continue

# If you need to abort the rebase
git rebase --abort

Backport a single fix to a release branch:

git checkout release/2.0
git cherry-pick 9f8e7d6

Common pitfalls and safety tips

• Do not rebase public branches that others have already pulled.
• Prefer rebase for cleaning your feature branch locally; prefer merge for integrating into main.
• During rebase, conflicts repeat per commit; take your time and test after each --continue.
• Use git log --oneline --graph --decorate --all to visualize history.
• Add context in PRs explaining why you chose merge vs rebase vs cherry-pick.

Team workflow recommendations

• Feature branches: rebase onto main before opening a PR to keep diffs small.
• Integration: merge PRs into main (no history rewrite on shared branches).
• Releases: cherry-pick targeted fixes into release/* branches.
• Automation: CI should run on every rebase/merge/cherry-pick to catch conflicts early.

Summary

• Merge: safest for shared history; adds a merge commit.
• Rebase: clean history for your branch; avoid rewriting shared branches.
• Cherry-pick: surgical commits across branches; great for fixes and backports.

Choose based on context: team policy, branch ownership, and whether you need the whole feature or just a specific fix.