Progress:
TIER 3 · MODULE 34· Expert

git merge-base

How merge and rebase decide what's new on each side.

🎯 What & why

Find the best common ancestor between commits. This is the commit merge uses as its base and rebase uses to decide which patches are 'yours'.

🧠 Mental model

History is a DAG; merge-base walks back from each input until it finds the youngest commit reachable from all of them. Get the base wrong and merges/rebases produce nonsense.

🛠️ Synopsis

git merge-base [--all] <commit> <commit>...
            git merge-base --octopus <commit>...
            git merge-base --independent <commit>...
            git merge-base --is-ancestor <commit> <commit>
            git merge-base --fork-point <ref> [<commit>]

🎚️ Switches & options

FlagWhat it does
<commit>...Two or more commits to find an ancestor for.
--allPrint every best common ancestor, not just one (criss-cross history).
--octopusCompute a single base suitable for an N-way octopus merge.
--independentReduce a list to those commits not reachable from the others.
--is-ancestor <a> <b>Exit 0 if <a> is an ancestor of <b>; for scripts, no output.
--fork-point <ref> [<commit>]Use the reflog of <ref> to find the point you originally branched from, even if <ref> was rewritten.

💡 Use cases

🧪 Examples

Base of feature vs main
git merge-base main feature
Is bugfix already in release?
git merge-base --is-ancestor abc1234 release/2.0 && echo yes
Fork point against rewritten upstream
git merge-base --fork-point origin/main
All bases (criss-cross)
git merge-base --all topic1 topic2

🎓 Recommendations

🪤 Common pitfalls

🔗 Related modules

📝 Quiz

Hit each option, then Check answers. Score is recorded; Next is always open.