git cherry命令参数差异及分支完整差异查询方法

Great question—let’s start by breaking down exactly how git cherry works, because that’s the key to clearing up your confusion.

Core Logic of git cherry #

First, let’s nail down the syntax and purpose:

git cherry <upstream> <head>

This command lists commits that exist in the <head> branch but do NOT have an equivalent patch in the <upstream> branch. Git uses a "patch-id" (a hash of the commit’s content, ignoring metadata like commit messages or timestamps) to judge equivalence—so two commits with the exact same code changes will be considered identical, even if their commit hashes are different.

Why git cherry master upstream vs git cherry upstream master Behave Differently #

Let’s translate each command into plain English:

• git cherry master upstream: "Show me commits that are in upstream but NOT in master" (here, upstream is the <head> branch we’re checking, master is the <upstream> baseline)
• git cherry upstream master: "Show me commits that are in master but NOT in upstream" (now master is the <head>, upstream is the baseline)

The reason the second command might have a longer output is context-dependent, but the most common scenario is:
Suppose upstream is a remote main branch that’s been updated by other contributors, while your local master only has a handful of your own changes. In this case:

• git cherry upstream master will only list your unique local commits (a small number)
• git cherry master upstream will list every new commit added to upstream since you last pulled (which could be dozens, hence the longer list)

Another edge case: if you’ve rebased or amended commits in master, their patch-ids might differ from equivalent commits in upstream, so git cherry will flag them as unique even if the code changes are the same.

git cherry feature master vs git cherry master feature #

This is just an extension of the same logic, applied to your master and feature branches:

• git cherry feature master: Lists commits that exist in master but have no equivalent in feature—these are the commits you might need to cherry-pick into feature.
• git cherry master feature: Lists commits that exist in feature but have no equivalent in master—these are the commits you might need to cherry-pick into master.

Of course these give different results! You’re asking two opposite questions: "What does A have that B doesn’t?" vs "What does B have that A doesn’t?" They’re two distinct sets of commits.

How to Get a Complete, Reliable List of Branch Differences #

If you want a full picture of all commits unique to either branch, here are the best approaches:

1. Combine git cherry Results #

Run both commands and merge their output:

# Get commits unique to master
git cherry feature master
# Get commits unique to feature
git cherry master feature

This is great if you specifically want commits that need cherry-picking (since git cherry filters out equivalent patches automatically).

2. Use git log for Visual Clarity #

Git’s range syntax makes it easy to see branch-specific commits:

• Show commits unique to master:

  git log --oneline feature..master
  

• Show commits unique to feature:

  git log --oneline master..feature
  

• Show all unique commits from both branches, with clear markers for which branch they belong to:

  git log --oneline --left-right master...feature
  

  The < marker means the commit is unique to master, > means it’s unique to feature.

3. Verify Equivalent Commits #

If you’re unsure whether a commit has already been cherry-picked (even with a different hash), use git patch-id to check:

# Get the patch-id of a commit from master
git show <master-commit-hash> | git patch-id
# Compare it to a commit from feature
git show <feature-commit-hash> | git patch-id

If the output hashes match, the commits are identical in content—no need to cherry-pick again.

内容的提问来源于stack exchange，提问作者Muhwu