To understand the compare view, it helps to picture the everyday question it’s specifically built to answer.

The problem: understanding the gap between two points

A project’s history often branches, diverges, and reconnects in ways that make a simple, single linear timeline insufficient for answering a very natural question: “what’s actually different between this branch and that one?” or “what changed between this release and the previous one?” Manually tracing through individual commits to piece together that answer is slow and genuinely error-prone.

The solution: a dedicated screen for exactly this question

The compare view is a dedicated interface specifically designed to answer that question directly. You choose a base point and a comparison point — two branches, two tags, two specific commits, or any mix of these — and the view calculates and displays exactly which commits and which file changes separate them, all in one clear, organized place.

The flexibility of the compare view comes from exactly how many different kinds of points it can compare against each other.

You’re not limited to comparing two branches — the compare view accepts branches, tags, or specific individual commits as either the base or the comparison point, in any combination you need. This flexibility makes it useful for a wide range of everyday questions, from “what’s changed since our last release tag” to “what’s different between these two specific commits I’m investigating.”

Understanding the underlying mechanics clarifies exactly what the compare view is doing behind its simple, clean interface.

Understanding the layout of what’s actually shown makes the compare view far easier to read quickly and accurately.

flowchart TD
    A["Base point selected"] --> C["Shared divergence point found"]
    B["Compare point selected"] --> C
    C --> D["Commits unique to compare side collected"]
    D --> E["Combined diff calculated across the range"]
    E --> F["Compare view displays commit list and combined diff"]
        

Tracing a typical use of the compare view, from an initial question through to an answer, shows how it supports real, everyday investigation.

Starting with a question

Someone wants to understand exactly what’s different between two specific points — perhaps preparing release notes, or investigating when a particular change was introduced.

Selecting the two points

They choose the appropriate base and compare points, which might be two tags representing releases, two branches, or two specific commits identified through other investigation.

Reviewing the results

They examine the commit list to understand the sequence of changes, and the combined diff to understand exactly what files and lines were affected in total across that entire range.

Taking action based on what’s found

The information gathered might inform writing release notes, opening a pull request directly from that comparison, or simply satisfying a specific, targeted investigative question.

The compare view offers substantial, genuine value for understanding history, alongside a few limitations worth knowing.

Beyond everyday development work, the compare view plays a genuinely useful role in security review and auditing.

When investigating exactly what changed between a known-good, trusted version and a currently deployed one, the compare view provides a precise, complete answer, letting an investigator examine the full combined diff for anything unexpected or concerning. This makes it a valuable tool for confirming that a deployed version genuinely, exactly matches what was reviewed and approved, with nothing unexpected slipped in between.

Experienced users tend to reach for the compare view in a similar, well-understood set of situations.

A few recurring mistakes lead to confusion or wasted effort when using the compare view.

Beyond the specific anti-patterns already covered, a broader set of habits helps get consistently accurate, useful results from the compare view.

The compare view sits alongside several related tools, each answering a slightly different kind of question.

Recognizing which tool fits a given question saves time — reaching for the compare view specifically when you have two clear points in mind, and reaching for other tools when your question is more open-ended or already tied to an existing pull request.

This tool sees constant, everyday use across professional teams and open-source projects investigating exactly what’s changed and why.

Release managers preparing accurate, complete release notes commonly rely on comparing the new release tag against the previous one, ensuring every meaningful change is captured and correctly attributed. Engineers investigating exactly when a particular bug was introduced frequently use targeted comparisons between specific commits to narrow down precisely which change is responsible, rather than manually reviewing an entire, sprawling history.

Yes. Any two branches, tags, or commits can be compared against each other directly, without needing to involve the main branch at all.

No. It specifically shows only what’s unique to the compare side relative to the shared starting point both sides diverged from, not the entire history either point has ever had.

Because the comparison is directional, measuring specifically what’s different on the compare side relative to the base. Swapping which side plays which role can produce a genuinely different, sometimes reversed-looking set of results.

Yes. The compare view is commonly the direct starting point for opening a pull request, letting you review the comparison first and then proceed straight into a formal request to merge.

It can be, though a very large range naturally takes longer to review thoroughly. Narrowing the comparison to a more specific, focused range often makes for a genuinely more manageable and useful result.

Generally, a meaningful comparison relies on the two points sharing some common history to establish a starting point for the comparison; entirely unrelated histories may not produce a genuinely useful result.

The compare view answers, precisely and directly, one of the most common questions in working with a project’s history: what actually separates these two specific points? By letting you select any combination of branches, tags, or individual commits as a base and a compare side, it calculates exactly which commits and which file changes make up the gap between them, presenting both the granular commit-by-commit detail and the overall combined picture together. Used deliberately — with a clear, specific question in mind and careful attention to which side plays which role — it becomes an indispensable tool for release preparation, security auditing, bug investigation, and previewing changes before they ever become a formal pull request.