Introduction

When people ask for commits only for a specific branch, they usually mean commits that exist on one branch but not on another. Git can answer that accurately, but only if the range expression matches your intent, because branches are just movable references and commits are included by reachability. The most important part is understanding range direction and merge behavior before relying on output for reviews, release notes, or automation.

Choose the Correct Range Syntax

Git log range syntax is powerful but easy to misuse.

• A..B means commits reachable from B and not reachable from A.
• A...B means symmetric difference, commits reachable from either side but not both.

For branch-only commits from feature compared to main, use two-dot syntax.

git log --oneline main..feature/payment-retry

This is directional. If you reverse the order, you get the opposite set.

git log --oneline feature/payment-retry..main

That small detail is a common source of incorrect changelogs.

Use Merge Base for Accurate Feature History

If branches were rebased or merged frequently, comparing directly with main can still include unexpected noise. A robust pattern is to compare from merge base.

BASE=$(git merge-base main feature/payment-retry)
git log --oneline "$BASE"..feature/payment-retry

This asks for commits introduced after the point where the branches diverged. It is usually what reviewers want.

Control Output for Different Use Cases

For human review, use graph and decoration.

git log --graph --decorate --oneline main..feature/payment-retry

For audit logs, include author and date.

git log main..feature/payment-retry \
  --pretty=format:'%H%x09%ad%x09%an%x09%s' \
  --date=iso-strict

For path-specific analysis in monorepos, scope by directory.

git log --oneline main..feature/payment-retry -- services/billing/

That keeps output relevant when a branch touches multiple subsystems.

Handle Merges and Cherry Picks Intentionally

Merge-heavy branches can make history hard to read. Decide your policy.

• Use full history when traceability matters.
• Use --first-parent for a linear narrative of integration.
• Use --no-merges when you only want content commits.

1# Linear branch story
2git log --first-parent --oneline main..feature/payment-retry
3
4# Exclude merge commits
5git log --no-merges --oneline main..feature/payment-retry

Cherry-picked commits are another edge case. Same logical change can have different commit hashes across branches. Use patch comparison when needed.

git cherry -v main feature/payment-retry

This helps identify duplicates before generating release notes.

If you need a very strict view of the direct line of work between two points, --ancestry-path can also help in some histories. It is more specialized than normal range queries, but useful when merge-heavy graphs create confusing side branches.

Automation-Friendly Commit Extraction

If a script consumes commit output, avoid free-form formatting and keep stable delimiters.

git log main..feature/payment-retry \
  --pretty=format:'%H|%an|%ad|%s' \
  --date=short > /tmp/branch_commits.txt

Then parse by delimiter in your toolchain. This is more reliable than parsing human output with variable spacing.

Example with simple shell filtering:

while IFS='|' read -r sha author date subject; do
  printf 'sha=%s author=%s date=%s subject=%s\n' "$sha" "$author" "$date" "$subject"
done < /tmp/branch_commits.txt

If commit subjects can include delimiters, use tab separators with %x09 instead.

Validate Results Before Publishing

Before using output in release notes or deployment decisions:

1. Confirm target and source branch names.
2. Confirm range direction.
3. Confirm merge policy flags.
4. Spot-check one or two SHAs with git show.

These checks catch almost every branch-log mistake early.

It is also worth confirming which branch is treated as the baseline in your release process. Teams often disagree about whether "branch-only commits" should be compared to main, the release branch, or the merge base with both.

Common Pitfalls

A frequent issue is using three-dot range when the requirement is one-branch-only commits. Another is accidentally swapping range order, which silently flips the result set. Teams also forget to define merge policy, causing reports to differ between local runs and CI jobs. In monorepos, missing path filters leads to noisy output that reviewers ignore. Finally, scripts that parse default pretty output break when author names or subjects contain unexpected spacing.

Summary

• Use A..B for commits on B not present on A.
• Prefer merge-base comparison for cleaner feature branch history.
• Decide whether merges are included, first-parent only, or excluded.
• Use stable, delimiter-based formatting for automation.
• Apply path filters in monorepos when you need subsystem-only history.
• Validate range direction and sample SHAs before publishing results.