Introduction

To know whether a branch has already been merged into master, you need to ask Git whether the branch tip is reachable from master. The simplest checks are built into git branch --merged and git merge-base. The main complication is not the command itself but the history style: rebases, squash merges, and stale remote refs can make "merged" mean slightly different things operationally.

Start with git branch --merged

If you want a quick local answer, switch to master and ask Git which branches are fully merged into the current branch:

git switch master
git branch --merged

If your feature branch appears in that list, its tip is reachable from master, which means Git considers it merged.

You can also ask directly:

git branch --merged master

This is the most convenient human-facing command for normal merge history.

Use merge-base --is-ancestor for a Scriptable Check

If you want a precise yes or no result, use:

git merge-base --is-ancestor feature-branch master
echo $?

Interpretation:

• '0 means feature-branch is an ancestor of master'
• non-zero means it is not

That makes this command especially useful in scripts or CI checks.

It is effectively asking: "Is every commit reachable from the feature branch tip already contained in master?"

Fetch First So You Are Asking About Current History

Before checking remote branches, update your refs:

git fetch origin --prune

Then inspect the remote branch against remote master:

git merge-base --is-ancestor origin/feature-branch origin/master
echo $?

Without a fresh fetch, you may be checking outdated local knowledge of the remote repository.

This is one of the most common sources of confusion. The command is correct, but the refs are stale.

Know the Difference Between Merge, Rebase, and Squash

These checks work cleanly when the branch was merged normally. But branch history style matters:

• normal merge commit: ancestor checks work well
• fast-forward merge: ancestor checks also work well
• rebase then merge: still usually fine if the rebased commits are what landed
• squash merge: the original branch tip is often not an ancestor anymore

In a squash-merge workflow, the changes may be present in master even though the original branch tip is not. In that case, Git may correctly report that the branch is not merged from a commit-graph perspective.

That is why "has it been merged?" can mean two different things:

• is the branch tip reachable from master
• are the branch changes present in master in some equivalent form

Git answers the first question directly. The second question is more semantic and harder to automate.

Use Log Comparisons When the Workflow Is Less Direct

If the history is unusual, inspect what commits are still unique to the branch:

git log master..feature-branch --oneline

If nothing prints, there are no commits on the branch that are absent from master under normal ancestry rules.

You can also compare the reverse direction:

git log feature-branch..master --oneline

These views help when the raw yes or no answer is not enough.

Common Pitfalls

• Checking local branch state without fetching updated remote refs first.
• Assuming squash merges preserve branch ancestry in the same way as normal merges.
• Treating "changes are present" and "branch tip is merged" as if they were always identical questions.
• Running git branch --merged from the wrong current branch and misreading the result.
• Deleting a branch based on stale assumptions instead of verifying against the relevant target branch explicitly.

Summary

• 'git branch --merged master is the easiest quick check for normal merge history.'
• 'git merge-base --is-ancestor branch master is the precise script-friendly test.'
• Fetch remote refs before checking remote merge status.
• Squash merges can make branch ancestry checks look negative even when similar changes landed.
• Be clear whether you care about branch-tip ancestry or about the presence of equivalent changes in the target branch.