Introduction

When a bug appears after integration, you often need to answer a precise question: which commits came through a specific merge commit. Git can provide this accurately, but only if you read parent relationships correctly and use the right revision range. A repeatable workflow prevents mistakes during incident debugging and release verification.

Step 1: Inspect Merge Parents

A merge commit has at least two parents. Parent one is usually the target branch tip before merge, and parent two is the merged branch tip.

git show --no-patch --pretty=raw <merge_sha>

or a shorter view:

git show --no-patch --pretty='%H %P' <merge_sha>

You must confirm parent order first. If you reverse the parents later, your commit list will answer a different question.

Step 2: List Commits Brought by the Merged Side

For merge commit M, this range is the common way to list commits that came from the merged branch:

git log --oneline M^1..M^2

A visual version helps when graphs are complex:

git log --graph --decorate --oneline M^1..M^2

Interpretation: commits reachable from M^2 that were not reachable from M^1 at merge time.

Step 3: See What Actually Landed in the Target Branch

Commit ancestry shows intent, but conflict resolution can introduce extra changes during merge. To inspect integrated patch content, compare the merge commit to its first parent.

git diff --name-status M^1 M

Full patch output:

git show --patch --stat M

This catches edits introduced during conflict handling that may not be obvious from the source branch commit list.

Useful Variants for Common Workflows

For release notes, first-parent history is often cleaner than full graph traversal.

git log --first-parent --oneline main

To inspect only merge commits:

git log --merges --oneline main

To check whether a specific commit was on the merged side:

git merge-base --is-ancestor <candidate_sha> M^2 && echo yes || echo no

These commands are useful for audit trails and ticket validation.

Merge Strategy Differences

The method above assumes a real merge commit exists. Strategy matters:

• merge commit workflow: parent-based ranges work directly
• squash merge workflow: original branch commits are collapsed
• rebase-and-merge workflow: commits are rewritten and linearized

For squash merges, rely on pull request metadata, commit message conventions, and platform APIs rather than parent range math.

Practical Incident Checklist

During incidents, use a checklist so no step is skipped.

1. git fetch --all --prune to avoid stale history.
2. Confirm merge SHA and parents.
3. List merged-side commits with M^1..M^2.
4. Inspect merge patch versus first parent.
5. Map suspicious commits to ticket IDs.

A scripted version can reduce operator error:

1#!/usr/bin/env bash
2set -euo pipefail
3
4merge_sha="$1"
5
6echo "merge: $merge_sha"
7echo "parents:"
8git show --no-patch --pretty='%P' "$merge_sha"
9
10echo "merged-side commits:"
11git log --oneline "${merge_sha}^1..${merge_sha}^2"
12
13echo "files changed by merge:"
14git diff --name-only "${merge_sha}^1" "$merge_sha"

Keep this in internal runbooks for on-call use.

Validate Local State Before Trusting Output

Many wrong conclusions come from stale local refs or detached worktrees. Always fetch and confirm the branch tip before analysis. If needed, run commands against explicit remote refs so output is reproducible across team members.

git fetch origin
git log --oneline origin/main --merges -n 20

Reproducibility matters when multiple engineers are debugging the same production regression.

Common Pitfalls

• Reversing M^1..M^2 and listing the wrong commit set.
• Assuming every merge policy creates a merge commit.
• Looking only at commit ancestry and missing conflict-resolution edits.
• Running analysis on stale local history.
• Ignoring parent order and drawing incorrect release conclusions.

Summary

• Start with merge parent inspection before any range queries.
• Use M^1..M^2 for merged-side commits in real merge-commit workflows.
• Compare M^1 and M to inspect actual integrated code changes.
• Adjust approach for squash and rebase-based merge strategies.
• Use a repeatable checklist or script for reliable incident and release analysis.