Git Merge vs Rebase vs Cherry-Pick: Comparing History Transformations

Advanced

Start with the state you need to change

The useful question is not which command sounds right. Identify the history transformation you need. Merge combines histories. Rebase replays a selected sequence onto a new base. Cherry-pick applies the change introduced by selected existing commits to the current history.

merge       → combine histories
rebase      → replay a sequence onto a new base
cherry-pick → apply selected commit changes

Two histories have diverged.?A merge result can contain both lines of ancestry.

Merge: combine histories

When histories have diverged and one branch is merged into another, the resulting history can contain a merge commit with both branch tips as parents. The operation integrates the histories rather than selecting only one commit change.

git switch main
git merge topic
git log --oneline --graph --decorate --all

The histories are divergent.?The merge result records the integrated ancestry.

Rebase: replay a sequence onto a new base

Rebase selects commits according to its upstream/base boundary, then reapplies them onto a different base. Replayed commits normally receive new identities because their parent context changes.

git switch topic
git rebase main
git log --oneline --graph --decorate --all

A topic sequence has an old base.?The sequence is replayed on the new base with new commit identities.

Cherry-pick: select particular commit changes

Cherry-pick is narrower: select one or more existing commits and apply the changes they introduce to the current history. It does not replay the entire source branch merely because the selected commits are related.

git switch maintenance
git cherry-pick <selected-commit>
git show --stat --oneline HEAD

A source branch contains multiple commits.?Only the selected commit change is applied.

Same change, different history shape

A merge, a rebase, and a cherry-pick can make destination files resemble the desired result while producing different commit graphs. File content alone is therefore insufficient; inspect parents, ancestry, commit identities, and refs.

git log --graph --oneline --decorate --all
git rev-list --parents -n 1 HEAD
git merge-base --is-ancestor <commit> HEAD

The destination files look correct.?History inspection proves the transformation as well.

Selection boundaries are different

Merge normally integrates a branch history. Rebase uses an upstream/base boundary to determine the sequence it replays. Cherry-pick names particular commits. Ask whether you want histories combined, a sequence relocated, or individual changes selected.

MERGE       branch/history integration
REBASE      commit sequence + new base
CHERRY-PICK named commit(s)

You have identified one existing commit to apply.?That commit change is applied to the current history.

Local transformation is not publication

Merge, rebase, and cherry-pick can change local history without publishing anything. A remote changes only when a separate remote operation such as git push updates its ref.

git log --oneline --decorate -n 5
git push origin main

A local history transformation has completed.?A separate push can publish the resulting ref.

A practical decision procedure

Use this sequence: identify the destination; decide whether the whole histories, a sequence of commits, or particular commit changes should be integrated; choose the corresponding transformation; then verify refs, parents, ancestry, and intended file changes.

Need both histories represented?        → merge
Need my sequence on a new base?          → rebase
Need these particular existing changes?   → cherry-pick
Then: inspect refs + parents + ancestry.

The operation has completed.?The destination state and history shape are verified.

Practice what you learned

Use the dedicated Git code-completion exercise for this lesson.