Introduction

If you want to see only the changes introduced by your current branch relative to master, you usually want a diff from the merge base, not a raw branch-to-branch comparison. That distinction matters because master may contain new commits that your branch has not merged yet, and those commits can clutter the diff.

Why a Plain Two-Branch Diff Is Often Wrong

Suppose the history looks like this:

• 'master: A -> B -> C -> D'
• 'feature: A -> B -> X -> Y'

If you run:

git diff master feature

Git compares the tips directly. That means the diff includes:

• Changes made on feature.
• Changes made on master after the branches split.

If your goal is "show me what this branch changed," that output is noisy because commits C and D were not authored on your branch.

Use the Merge Base

The merge base is the common ancestor where the two branches diverged. To see only the changes introduced on your current branch since that point, diff from the merge base to HEAD:

git diff $(git merge-base master HEAD) HEAD

This is the precise version of the query. It says:

1. Find the shared ancestor of master and the current branch.
2. Compare that commit to the current branch tip.

That excludes unmerged master commits by design.

The Short Form With Three Dots

Git provides a shortcut for the same idea:

git diff master...HEAD

In git diff, the three-dot form means "diff the merge base of the two revisions against the second revision." When you are on the feature branch, master...HEAD is usually the most convenient command.

If your main branch is named main, use:

git diff main...HEAD

This is the command most developers want during code review or pre-merge inspection.

See Only File Names or a Summary

Sometimes you do not want the full patch. You can combine the same revision selection with summary flags:

git diff --stat master...HEAD
git diff --name-only master...HEAD

These are useful when you want a quick scope check before opening the full patch.

Compare Against Another Branch Explicitly

If you are not on the target branch, replace HEAD with the branch name:

git diff master...feature/login-page

That still means "show the changes introduced by feature/login-page since it diverged from master."

This is safer than checking out branches repeatedly just to inspect the diff.

Be Careful Not to Confuse git diff and git log

The ... notation behaves differently in different Git commands. In git log, three dots mean "commits reachable from either side but not both." In git diff, the three-dot form uses the merge base and compares against the second endpoint.

That difference confuses people because the syntax looks identical but the meaning is command-specific.

If the shortcut feels unclear, use the explicit form with git merge-base. It is longer, but there is no ambiguity:

git diff $(git merge-base master HEAD) HEAD

Common Pitfalls

• Running git diff master HEAD and assuming it shows only branch-specific work.
• Forgetting that unmerged commits on master change the result of a direct tip-to-tip diff.
• Mixing up the meaning of ... in git diff and git log.
• Using master in examples when the repository actually uses main.
• Reviewing only commit lists when the real question is about file-level content differences.

Summary

• To exclude unmerged commits from master, diff from the merge base to your branch.
• The explicit command is git diff $(git merge-base master HEAD) HEAD.
• The common shorthand is git diff master...HEAD.
• Use --stat or --name-only if you want a lighter-weight summary first.
• Remember that the three-dot syntax means different things in different Git commands.