- Developers who already know basic commit and branch actions
- Readers who want to understand command boundaries and risk
Command Reference
git-cherry Tutorial
Explains how to use git-cherry to check which commits have not yet been integrated elsewhere.
- A basic mental model of worktree, index, and commits
- Comfort reading `git status` and a small commit graph
- Using local cleanup commands on already shared history
- Continuing to rewrite before confirming a recovery path
The short version
git-cherry is used to check which commits have not yet been integrated elsewhere.
When it is a good fit
- when you need to check which commits have not yet been integrated elsewhere
- when you want this step to be repeatable instead of ad hoc
- when you need a clearer mental model of what Git is recording or updating
Basic example
git cherry origin/main feature/login
What to watch most closely
Advanced commands are not always part of the daily path, but mistakes with them usually cost more to recover from.
A safer working habit
Rehearse the flow on a small reproducible history before running it in a production repository.
Useful angles for understanding it
- Handle more complex collaboration or history-analysis tasks
- Turn one-off steps into repeatable routines
- Reduce the risk of advanced operations
Related reading
Read it alongside git status, git log, and git show so it is easier to see how the command changes history, refs, the index, or the working tree.
What problem this command solves in a workflow
git cherry is a read-only comparison tool that identifies which commits from one branch have not yet been applied to another. It uses patch-id comparison rather than commit hash matching, so it correctly recognizes commits that were cherry-picked or rebased (same patch content, different hash). Lines prefixed with + are commits not yet in the upstream; lines prefixed with - are commits already applied.
Typical use cases
- Checking which commits from a feature branch still need to be merged or cherry-picked into a release branch.
- Verifying after a cherry-pick or rebase that all intended patches landed on the target branch.
- Comparing two branches before deciding on a merge strategy — cherry shows you the delta at the patch level.
- Release management: confirming which fixes from a development branch have already reached the stable branch.
Diagram view
Upstream branchFeature branchPatch content
+ commits (not yet upstream)- commits (already applied)No refs changed
Cherry is read-only. It compares patch content — the same change with a different hash will still be recognized as applied.
Special cases and boundaries
- Cherry uses patch-id, which is computed from the diff. If a commit was applied with manual conflict resolution, the patch-id may differ and it will show up as
+(unapplied) even though the intent was addressed. - Cherry compares against a single upstream. If you need to check across multiple branches, you must run it separately for each.
- Cherry only compares commit patches — it does not show changes in the working tree or index. Make sure both branches are up to date before running.
- For a more detailed comparison between two versions of a patch series, consider
git range-diffinstead, which shows how individual patches evolved between versions. - Cherry is a read-only reporting tool. It never moves refs or modifies history.