Introduction

git log becomes noisy quickly in repositories with active branching. Most of the time, the real question is not “show me every commit reachable from this branch,” but “show me what is unique to this branch compared with some base branch.” Git can answer that cleanly, but the range syntax matters.

Start with a Plain Branch Log

If you just want the history reachable from a branch tip, give git log the branch name:

git log feature/auth-rework

This shows commits reachable from feature/auth-rework, including commits that also exist on main. It is useful for a general look, but it does not isolate branch-only work.

For a compact view:

git log --oneline feature/auth-rework

For a graph view:

git log --oneline --decorate --graph feature/auth-rework

These views are helpful, but they still include shared history.

Show Commits Unique to One Branch

To see commits that exist on your branch but not on main, use two-dot range syntax:

git log --oneline main..feature/auth-rework

Interpretation:

• left side is the baseline
• right side is the branch you care about
• output is everything reachable from the right side and not from the left side

This is usually the best answer to “what changed only on this branch.”

If you are currently checked out on the branch, HEAD is often more convenient:

git log --oneline origin/main..HEAD

That avoids hard-coding the current branch name.

Compare in the Other Direction

If you want to know what main has that your branch does not, reverse the range:

git log --oneline feature/auth-rework..main

This is useful when you are preparing to rebase or checking whether your feature branch is behind.

Use Three Dots for Symmetric Difference

Three-dot syntax answers a different question: what commits are on either branch but not both.

git log --oneline --left-right main...feature/auth-rework

With --left-right, Git prefixes commits so you can see which side they belong to. This is helpful when reviewing divergence between branches rather than just branch-only work in one direction.

Include File-Level Details

Commit messages are not always enough. Add file detail when you need to review what actually changed.

Names and status:

git log --name-status --oneline origin/main..HEAD

Diff summary:

git log --stat origin/main..HEAD

Full patch:

git log -p origin/main..HEAD

Use patch output carefully on large branches because it gets long fast.

Filter by Author, Date, or Path

Range syntax combines well with other filters.

By author:

git log --oneline origin/main..HEAD --author="alex"

By date:

git log --oneline origin/main..HEAD --since="2026-01-01"

By path:

git log --oneline origin/main..HEAD -- src/auth/

The -- separator matters when filtering by file or folder path.

Fetch Before Comparing

Branch comparison is only useful if your local refs are current. If you compare against stale local main, the output can be misleading.

git fetch origin
git log --oneline origin/main..HEAD

This is a better habit than comparing against an outdated local branch pointer.

Useful Review Workflow

A clean pre-review sequence often looks like this:

1. fetch the latest remote refs
2. inspect unique commits on the current branch
3. inspect file-level changes
4. confirm there are no unintended commits

Example:

git fetch origin
git log --oneline origin/main..HEAD
git log --name-status origin/main..HEAD

That gives a good pull-request sanity check before pushing or opening review.

Common Pitfalls

The most common mistake is running git log branch-name and assuming the result is unique to that branch. It is not. It is simply everything reachable from that branch tip.

Another issue is mixing up two-dot and three-dot syntax. Two dots answer a one-direction comparison. Three dots show the symmetric difference.

Developers also often compare against stale local main instead of freshly fetched origin/main, which produces incorrect conclusions about what is unique to the branch.

Summary

• Use git log base..branch to see commits unique to one branch.
• Use git log branch only when you want all history reachable from that branch tip.
• Use three-dot syntax with --left-right for symmetric branch comparison.
• Add --name-status, --stat, or -p when commit messages are not enough.
• Fetch before comparing so branch-specific history reflects current remote state.