Moving One Commit Instead of a Whole Branch

git merge and git rebase both integrate all commits from one branch into another. That's their normal, intended use. But sometimes you need only a single commit applied to your current branch — not everything else that happened on the source branch. That's when git cherry-pick comes in.

As the name suggests, cherry-picking lets you take one specific commit and apply it to your current HEAD branch. The commit's changes and message are copied over, but it remains a separate, new commit with its own ID. The original is left untouched on its branch.

A Common Use Case: Commit on the Wrong Branch

Consider a mistake many developers have made at some point: you commit a change to master when it was meant for a feature branch like feature/newsletter. Checking git log shows the offending commit sitting on the wrong branch:

Showing the Tower app UI with a commit history of a master branch. Red arrows point to the most recent commit and the newsletter branch,. indicating that is where the commit was intended to go.

To fix this without reverting and recommitting by hand, switch to the correct branch and run git cherry-pick with the commit ID:

$ git checkout feature/newsletter
Switched to branch 'feature/newsletter'
$ git status
On branch feature/newsletter
nothing to commit, working tree clean
$ git cherry-pick 26bf1b48
[feature/newsletter 7fb55d0] Newsletter signup page
 Author: Tobias Günther <[email protected]>
 Date: Fri Oct 5 09:58:03 2018 +0200
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 signup.html

Running git log on the feature branch confirms the commit is now present there:

$ git log
commit 7fb55d06a8e70fdce46921a8a3d3a9de7f7fb8d7 (HEAD -> feature/newsletter)
Author: Tobias Günther <[email protected]>
Date:   Fri Oct 5 09:58:03 2018 +0200

    Newsletter signup page

It's important to note that cherry-picking does not move the commit — it copies it. The original remains on master. You can think of it as applying the same patch to a new location in your history.

Cleaning up the Original Branch

After the cherry-pick succeeds, you still have the errant commit on master. To remove it, use git reset to roll the branch back:

$ git checkout master
Switched to branch 'master'
$ git reset --hard HEAD~1
HEAD is now at 776f8ca Change about title and delete error page

Once the reset is complete, the mistaken commit is gone from master, and the feature branch has the change it needed. The scenario is resolved as if the commit had been made on the right branch from the start.

When to Reach for Cherry-Pick

Cherry-picking should be the exception, not the rule. Merge and rebase exist to integrate complete lines of development, and they remain the correct tools for that job. Reserve cherry-pick for situations where integrating only one or a few commits makes sense — such as moving a misplaced commit, applying an urgent hotfix from a maintenance branch, or bringing over a select change without pulling in an entire branch's worth of development.

Keep in mind that because cherry-pick creates a duplicate commit, the original branch will still contain its version unless you clean it up with a reset or revert. And if you cherry-pick a commit that you later also merge through a long-lived branch, you may end up with conflict or duplication issues down the road — another reason to treat this command for special cases, not everyday integration.