CodeOath
← All posts
Git65 min total · 17 parts

Git Internals and Workflows: Branching, Merging, and Rebasing

Contents — Part 10 of 17: Cherry-Picking Commits
Part 10 of 17 · ~1 min

Cherry-Picking Commits

git cherry-pick <commit> applies the changes from one specific commit (from anywhere in the repository's history, on any branch) onto your current branch, as a new commit with a new hash — useful for pulling a single fix across branches without merging or rebasing everything else that branch contains:

git switch main
git cherry-pick a1b2c3d   # apply just this one commit from another branch onto main

A common real scenario: a hotfix was committed directly on a release branch, and it also needs to land on main without merging the entire release branch (which might contain other in-progress work) into main. Cherry-picking, like rebasing, creates a commit with a different hash than the original even though the change is identical — which means Git doesn't automatically know these two commits are "the same change" if it later needs to merge the two branches; this can occasionally produce a conflict or an unexpected duplicate-looking diff down the line, worth being aware of on branches that get both cherry-picked and eventually merged.