Introduction

If a GitHub pull request shows commits that you believe are already in the target branch, the problem is usually branch history, not GitHub being random. Pull requests are based on commit ancestry, so unusual rebases, merges, cherry-picks, or the wrong base branch can make the commit list look noisy.

The good news is that this is usually fixable once you inspect the branch graph. The key question is not "why does GitHub show these commits" but "what history relationship does GitHub think exists between these two branches?"

Why the Commit List Looks Wrong

GitHub decides which commits belong to a pull request by comparing the source branch against the base branch from their merge base. If the source branch contains commits that are not ancestors of the current base branch in the expected way, GitHub may list commits that feel duplicated or already merged.

Common reasons include:

• the pull request targets the wrong base branch
• the feature branch was created from another feature branch
• commits were cherry-picked, so the content is present but the commit identities differ
• rebasing or merging changed the branch ancestry in a confusing way

This is why the "Files changed" tab can look reasonable while the "Commits" tab still looks strange.

Inspect the Branch Relationship Locally

Before rewriting history, inspect the graph:

git fetch origin
git log --oneline --graph --decorate origin/main your-branch
git merge-base origin/main your-branch

This tells you:

• what commits are actually on each branch
• where Git sees the shared ancestor
• whether your branch contains unexpected merged history

If the wrong base branch was selected on GitHub, fix that first. It is the least destructive explanation and often the actual cause.

Rebase Onto the Intended Base Branch

If the branch simply drifted and should be based on main, rebasing can clean the history:

git checkout your-branch
git fetch origin
git rebase origin/main

After that, force-push the rewritten branch:

git push --force-with-lease origin your-branch

This works best when:

• the branch is yours to rewrite
• the branch should be a clean sequence on top of the current base
• the extra commits are appearing because of history shape, not because the content is actually unique

Use --force-with-lease, not plain --force, so you do not accidentally overwrite someone else's new work.

Recreate the Branch If History Is Too Tangled

Sometimes the cleanest fix is to create a fresh branch from the intended base and cherry-pick only the commits that should be reviewed:

git checkout -b clean-pr origin/main
git cherry-pick <commit1> <commit2>
git push -u origin clean-pr

This is often easier than untangling a branch that was:

• branched from the wrong place
• merged with several temporary branches
• rebased multiple times
• polluted by unrelated experiment commits

If the pull request history is messy enough, a clean branch is faster than trying to rescue the old one.

Understand Cherry-Pick Versus Merge Identity

One subtle case is worth calling out. If a commit was cherry-picked into the target branch, GitHub may still show the original commit from your branch as separate history. The file content may already exist in the target branch, but the commit IDs are different, so Git does not treat them as the same commit.

That is not a GitHub bug. Git tracks commits by identity and ancestry, not by "this patch looks kind of familiar."

Common Pitfalls

• Assuming the GitHub commit list is purely content-based. It is ancestry-based.
• Rebasing or force-pushing without first confirming that the base branch itself is correct.
• Forgetting that cherry-picked commits are new commits with different identities.
• Trying to repair a hopelessly tangled branch when a clean branch plus cherry-pick would be simpler.
• Using plain git push --force instead of --force-with-lease.

Summary

• Pull requests show commits based on branch history, not just on file differences.
• The most common causes are wrong base branch selection, tangled ancestry, rebases, merges, or cherry-picks.
• Inspect the graph locally before making changes.
• Rebase when the branch should cleanly sit on top of the target branch.
• If the history is too messy, create a fresh branch from the correct base and cherry-pick only the intended commits.