Git Rebase vs Cherry-Pick: Alternatives to Git Merge

Git Rebase vs Cherry-Pick: Alternatives to Git Merge

Git merge, rebase and cherry-pick all integrate changes, but they do it in different ways. A merge joins development histories, a rebase replays a series of commits onto a new base, and cherry-pick applies the changes from selected commits onto another branch.

The right choice depends on what you are trying to preserve: the original branch history, a linear history, or only a specific change.

In our previous article on Git merge conflicts, we looked at traditional merge workflows and conflict resolution. Here we will focus on rebase and cherry-pick, how they change the commit graph, and when each technique makes sense.

Git Merge vs Rebase vs Cherry-Pick

Operation	What it does	Typical reason to use it
Merge	Joins two development histories, usually preserving the existing branch topology	Integrate a complete branch while retaining its history
Rebase	Replays commits onto a new base, creating new commits with new IDs	Update a branch and create a more linear history
Cherry-pick	Applies the change introduced by one or more selected commits and creates new commits on the current branch	Bring across a particular fix or change without integrating the whole branch

None of these is universally “better”. They represent different history and collaboration choices.

Understanding Git Rebase

git rebase takes commits that are unique to your branch and reapplies them on top of another base commit.

Suppose the history looks like this:

Before rebase

       A---B---C  (Branch1)
      /
D---E---F---G    (Branch2)

If you rebase Branch1 onto Branch2, Git replays the changes introduced by A, B and C on top of G:

D---E---F---G---A'---B'---C'  (Branch1)
            ^
         Branch2

The apostrophes matter. A’, B’ and C’ are new commits. They may represent the same changes as A, B and C, but rebasing rewrites the commits and therefore gives them new commit IDs.

A typical command would be:

git switch Branch1
git rebase Branch2

The result is a linear history that makes it appear as though the work on Branch1 started from the latest point on Branch2.

When rebase is useful

Rebase is particularly useful when you want to:

• update a local feature branch with the latest target-branch changes;
• avoid an additional merge commit purely for synchronisation;
• keep a straightforward, linear sequence of commits;
• clean up your own unpublished history before sharing it.

The Important Rebase Warning

Because rebase rewrites commits, be careful when rebasing history that other people are already using.

If commits have been pushed to a shared branch and teammates have based work on those exact commits, rebasing and force-pushing the rewritten history can make collaboration unnecessarily difficult.

A useful rule is:

Rebase your own local or otherwise coordinated history; do not casually rewrite shared history that other people have built work on.

Understanding Git Cherry-Pick

git cherry-pick is more selective. Instead of integrating an entire branch, it applies the change introduced by one or more chosen commits to your current branch.

Imagine this history:

       A---B---C---D  (Branch1)
      /
E---F---G            (Branch2)

If you want the change from commit C on Branch2, you can cherry-pick it:

       A---B---C---D  (Branch1)
      /
E---F---G---C'       (Branch2)

Again, C’ is a new commit. It contains the change introduced by C, but it has a different commit ID because it has been applied in a different place in history.

A typical workflow is:

git switch Branch2
git cherry-pick <commit-hash-for-C>

When cherry-pick is useful

Cherry-pick is a good fit when you need to:

• backport a bug fix to an older maintenance or release branch;
• bring one approved change into another branch without taking unrelated work;
• recover a useful commit that was made on the wrong branch;
• select only a small number of commits from a larger line of development.

For public backports, Git also provides git cherry-pick -x, which appends the source commit reference to the new commit message. That can be useful when you want the history to show where the backported change came from.

How Conflicts Work During Rebase and Cherry-Pick

Rebase and cherry-pick do not eliminate merge conflicts.

If Git cannot cleanly apply a commit to its new context, it pauses the operation and asks you to resolve the conflict.

During a rebase

After resolving the conflicted files:

git add path/to/resolved-file
git rebase --continue

If you decide the rebase should not proceed:

git rebase --abort

During a cherry-pick

After resolving the conflict:

git add path/to/resolved-file
git cherry-pick --continue

Or return to the state before the cherry-pick began:

git cherry-pick --abort

The important part is the same as with a normal merge: understand both changes before choosing the final content. The fact that you are rebasing or cherry-picking does not make an automatic resolution correct.

Handling Whitespace-Heavy Conflicts

The original version of this article mentioned Git’s whitespace strategy options, and that advice is still current.

Git’s default ort merge strategy supports options such as:

-Xignore-space-change
-Xignore-all-space

These can help when the apparent conflict comes primarily from formatting differences such as changed indentation or whitespace.

They should be used carefully. Git does not simply discard every line that contains whitespace; when whitespace changes are mixed with substantive code changes, normal merge behaviour still applies.

It is generally better to prevent widespread formatting-only diffs with consistent formatter and editor configuration than to rely on conflict-resolution flags later.

For Repeated Conflicts, Use Git rerere—Not a Conflict-Resolving Hook

The original 2023 article suggested using Git hooks to automatically resolve merge, rebase and cherry-pick conflicts.

That needs correcting.

Hooks are useful for guardrails, but standard hooks are not a general automatic conflict-resolution mechanism.

For example:

• pre-rebase can inspect or prevent a rebase before it starts;
• pre-merge-commit runs only after a merge has already succeeded, before the merge commit is created;
• if a merge fails because of conflicts, pre-merge-commit is not invoked to resolve them.

If your team repeatedly encounters the same conflict, Git has a more appropriate feature: rerere (“reuse recorded resolution”).

Enable it with:

git config --global rerere.enabled true

Git can then record how you manually resolved a conflict and reuse that resolution when it encounters an equivalent conflict later.

You should still inspect and test the result before committing it.

For highly predictable file-specific merge behaviour, Git also supports custom merge drivers through .gitattributes and Git configuration. These are a better fit than generic hooks when a particular file format has deterministic merge rules.

What Bitbucket Supports Today

If you are using Bitbucket, you do not necessarily need to perform every history strategy manually at the command line when merging a pull request.

Current Bitbucket Cloud supports pull-request strategies including merge commit, fast forward (implemented as --ff-only), rebase + merge, rebase + fast-forward, squash, and squash + fast-forward only.

Bitbucket Data Center provides the same broad choices and also exposes fast-forward and fast-forward only as separate strategy options.

One useful distinction: Bitbucket’s rebase merge strategies rebase the incoming commits as part of the pull-request merge operation; Atlassian documents that the source PR branch itself is not modified by that operation.

Cherry-pick is different. It is a selective commit operation rather than a pull-request merge strategy. Use it when you deliberately want particular commits rather than the complete branch history.

Bitbucket allows administrators to configure which merge strategies are available, so teams can standardise how pull-request history is created rather than leaving every merge decision unconstrained.

Which Should You Use?

If you want to…	Usually consider…
Preserve the relationship between two diverged branches	Merge
Put your own feature work on top of the latest target branch with a linear history	Rebase
Bring one specific bug fix into another branch	Cherry-pick
Turn a branch’s many commits into one target-branch commit	Squash
Update a branch pointer only when histories have not diverged	Fast-forward

The best choice is the one that matches the history you want your team to maintain.

Bottom Line

Rebase and cherry-pick are alternatives to a traditional merge for specific integration jobs, but they are not interchangeable.

Use rebase when you want to replay a sequence of commits onto a new base and are comfortable rewriting those commits.

Use cherry-pick when you want to apply selected changes without integrating the complete branch.

Use merge when preserving the branch relationship is more important than producing a linear history.

And when conflicts occur, treat them as a code-integration decision—not something that should be blindly “automated away”.

Git can help with repeated resolutions through rerere and custom merge drivers, but the final result still needs to represent the intended code.

Related Reading

For the underlying conflict-resolution workflow, see Advanced Git Merge Conflict Resolution Techniques.

If you use Bitbucket pull requests and want to optimise what happens before code is merged, see How to Optimize a Bitbucket Code Review Workflow.

By Sean Manwarring, Head of Marketing at Izymes
Published 20 September 2023 · Updated 19 October 2026