Compare two Git branches
Choose endpoint diffs, merge-base diffs, or commit ranges to compare Git branches, then generate and check a patch when you need to transfer file changes.
Use git diff A B to compare the file snapshots at two branch tips. Use git log A..B to list commits reachable from B but not A. These answer different questions, and the dots mean different things to diff and log.
Compare the current file snapshots
git diff main feature-x
git diff --stat main feature-x
git diff main feature-x -- src/api/
The first command shows the changes needed to turn the main snapshot into feature-x. The next two limit the output to a summary or a directory. git diff main..feature-x is another spelling of the same endpoint comparison.
Because this compares two final snapshots, changes present only on main appear too. They are differences between the branches, even if the feature author never touched those lines.
Compare a branch with its merge base
git diff main...feature-x
This compares a merge base of the branches with the feature-x tip. It is useful for reviewing changes on the feature side without also showing later changes that exist only on main.
The direction matters: git diff feature-x...main instead shows the main-side changes from the merge base. A merge base is derived from the commit graph, not necessarily a single historical moment when someone created a branch.
Use the endpoint comparison to ask “How do these versions differ now?” Use the merge-base comparison to inspect the feature’s changes relative to shared ancestry. Neither simulates a merge or guarantees a conflict-free result. Unrelated histories have no merge base, and complex histories with multiple merge bases need closer inspection.
Compare the commit histories
git log --oneline main..feature-x
git log --left-right --oneline main...feature-x
The two-dot log lists commits reachable from feature-x and excluded by main. The three-dot log lists commits exclusive to either side; < marks the left side and > the right.
These are ancestry-based comparisons. A cherry-picked commit has a different identity even when it applies an equivalent patch, so it can appear as unique history. Do not read a commit count as a count of distinct code changes.
Do I need to switch branches first?
No. These commands accept branch names directly and leave the checkout alone. To compare current remote state, first fetch from the intended remote, then use its remote-tracking refs:
git fetch origin
git diff origin/main...origin/feature-x
This assumes those refs are included in your fetch configuration and the branches exist remotely. Without a fresh fetch, remote-tracking refs may reflect an older state.
Export a patch
To export the endpoint difference, including binary changes:
git diff --binary main feature-x > changes.patch
In a checkout with the expected base content, check applicability before applying it:
git apply --check changes.patch
git apply changes.patch
The check does not modify files. Applying the patch changes the working tree; it does not create commits or preserve their messages and authors. Review and test the result before staging it. If the destination differs, patch application may fail or require deliberate conflict handling. Use a commit-oriented workflow such as git format-patch and git am when transferring commits is the goal.
Can I do this in an IDE?
Git clients, GitLens, and JetBrains IDEs offer branch comparison views. Check whether the view compares tip snapshots, merge-base changes, or commit lists: those views can look similar while answering different questions. The explicit commands above provide a way to confirm the comparison you intended.
References
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan