Introduction

In repositories with many feature branches, plain git log master can include commits that were authored elsewhere and later merged. If you want only commits made on the master branch path itself, you need the right history traversal options. The most useful flags are --first-parent, branch set subtraction, and path filtering.

What “Only Master Commits” Usually Means

Teams often mean one of two things:

• commits that are unique to master compared with another branch
• commits that occurred directly on the master first-parent line

These produce different outputs. Clarify which one you need before building reports or release notes.

Use --first-parent for Mainline History

For release history and merge overview, this is the most practical command:

git log master --first-parent --oneline

--first-parent follows the mainline path of master and avoids expanding all commits from merged feature branches. You still see merge commits, but not every side-branch commit.

Add graph for readability:

git log master --first-parent --graph --oneline --decorate

Show Commits Unique to master

To show commits reachable from master but not from another branch:

git log master ^develop --oneline

Equivalent range form:

git log develop..master --oneline

This is useful for release diff checks between long-lived branches.

Restrict to Non-Merge Commits

If you want only direct commit objects and no merge commits:

git log master --first-parent --no-merges --oneline

This is helpful when auditing individual hotfix commits applied directly on master.

Filter by Time, Author, or Path

Common practical filters:

git log master --first-parent --since="2026-01-01" --oneline

git log master --first-parent --author="[email protected]" --oneline

git log master --first-parent -- src/api/ --oneline

Combining traversal control with targeted filters gives cleaner outputs than post-processing raw logs.

Detect Commits Introduced by Merge Operations

If release process uses merge commits, inspect merges and then inspect each merge if needed.

git log master --first-parent --merges --oneline

Then inspect one merge:

git show <merge-commit-hash>

This helps tie release branch integration events to specific timelines.

Use git rev-list for Scriptable Output

When integrating with scripts, rev-list is stable and machine-friendly.

git rev-list --first-parent master

For unique commits relative to develop:

git rev-list develop..master

You can pipe hashes into other commands for CI checks or changelog tooling.

master Versus main

Many repositories now use main instead of master. Replace branch name accordingly:

git log main --first-parent --oneline

If tooling is shared across repos, parameterize branch name rather than hardcoding.

Reliable Team Workflow

A practical team pattern:

1. use --first-parent for release timeline
2. use range comparison for what changed since last release branch
3. apply path or author filters only when needed
4. pin command format in team docs for consistent reports

Consistency avoids confusion when different engineers generate different commit lists for the same question.

Common Pitfalls

• Using plain git log master and assuming it means direct master-only commits.
• Confusing unique commit ranges with first-parent traversal history.
• Forgetting that merged branch commits are still reachable from master.
• Mixing branch names across repositories that use main and master differently.
• Generating release notes without standardizing traversal flags.

Summary

• “Only master commits” is ambiguous, so define output intent first.
• '--first-parent is best for mainline branch history.'
• Branch range syntax shows commits unique to one branch versus another.
• '--no-merges, time filters, and path filters refine output further.'
• Standardize log commands in team workflows for reproducible history reports.