- Developers who already know basic commit and branch actions
- Readers who want to understand command boundaries and risk
Command Reference
git-merge-base Tutorial
Explains how to use git-merge-base to find the best common ancestor between histories.
- A basic mental model of worktree, index, and commits
- Comfort reading `git status` and a small commit graph
- Using local cleanup commands on already shared history
- Continuing to rewrite before confirming a recovery path
The short version
git-merge-base is used to find the best common ancestor between histories.
When it is a good fit
- when you need to find the best common ancestor between histories
- when you want this step to be repeatable instead of ad hoc
- when you need a clearer mental model of what Git is recording or updating
Basic example
git merge-base main feature/login
What to watch most closely
Plumbing commands are closer to Git internals, so check whether a safer high-level command already solves the problem.
A safer working habit
Treat it as a read-only inspection tool first, then move to write-oriented usage only when necessary.
Useful angles for understanding it
- Inspect lower-level objects and refs
- Write scripts or debug advanced issues
- Verify internal repository state
Related reading
Read it alongside git status, git log, and git show so it is easier to see how the command changes history, refs, the index, or the working tree.
What problem this command solves in a workflow
git merge-base is a read-only analysis tool that computes the best common ancestor(s) between two or more commits. It does not modify history, move refs, or create new objects. Instead, it answers: "where did these branches diverge?" This is the foundation that Git uses internally for three-way merges, rebase operations, and diff calculations.
Typical use cases
- Determining the exact point where two branches split, so you can construct a meaningful diff:
git diff $(git merge-base A B)..B. - Scripting: programmatically computing merge bases in CI/CD pipelines, release scripts, or automation that needs to compare branches at the divergence point.
- Understanding branch topology: when multiple branches exist, merge-base reveals the actual shared ancestry versus what a linear log might suggest.
- Preparing for rebases or cherry-picks: knowing the merge base helps you understand what range of commits will be replayed.
Diagram view
Commit ACommit BCommit graph
Best common ancestor commit hashNo refs changedNo history modified
Merge-base is purely analytical — it reads the commit graph and reports a result without changing anything.
Special cases and boundaries
- With
--fork-point, merge-base uses reflog data to find a more accurate divergence point, which is especially useful after a rebase has rewritten commit hashes. - When branches have multiple common ancestors (criss-cross merges),
git merge-base --alllists all of them. The "best" single ancestor may not capture the full picture. - Merge-base returns only commit hashes — it does not produce diffs or explain what changed. Pair it with
git difforgit logfor full context. - For octopus merges (more than two branches), merge-base can compute a common base across all inputs, but the result may be less intuitive than pairwise analysis.
- Merge-base is entirely read-only. It never writes to the repository, moves refs, or creates objects.