Reading a Git Diff Without the Guesswork
The unified diff is the lingua franca of code review. Git prints it, pull requests render it, and patch files store it. At first glance it is a jumble of pluses, minuses and @@ symbols, but the format follows a small, consistent grammar. Once you know the pieces, you can read any diff at a glance.
The header and the hunks
A diff starts with two lines naming the files being compared: one prefixed with --- for the original and one with +++ for the modified version, conventionally written as a/file and b/file. After that come one or more hunks — the actual regions of change. Each hunk opens with a line wrapped in @@ markers, like @@ -12,7 +12,9 @@. Those numbers say where the hunk sits: minus is the old file, plus is the new one, and each pair is a starting line number and how many lines the hunk spans.
You rarely need to do arithmetic with those numbers by hand, but knowing what they mean removes the mystery. When a review tool lets you jump between hunks, it is simply moving from one @@ block to the next.
Plus, minus and context
Inside a hunk every line carries a one-character prefix. A minus means the line was in the original and was removed. A plus means the line is new. A space means the line is unchanged and is shown only for context, so you can see the surroundings of the edit. By default a diff includes three context lines above and below each change, which is usually enough to locate it without printing the whole file.
A modification appears as a minus line immediately followed by a plus line: the old version, then the new one. Trained on this pattern, your eye learns to pair them automatically and read a replacement as a single change rather than two unrelated events.
Unified, split, and reviewing well
The raw text format above is the unified view. Many tools also offer a split view that places the old and new files in two columns side by side, which some people find easier for large changes. Neither is more correct — they present the same hunks differently. DiffScope gives you both from the same comparison, plus word-level highlighting the plain-text format cannot show.
To review efficiently, read a hunk's context first to anchor yourself, then the minus lines, then the plus lines, and ask whether the change does what the surrounding code implies it should. Paste a before-and-after into DiffScope, download the .patch, and you have a portable record of exactly what changed.
The takeaway
A unified diff names the files with --- and +++, splits changes into @@ hunks, and marks each line with minus (removed), plus (added) or space (context). Read context, then removals, then additions — and switch to a split view when a change is large.
Open the tool and try it now
More guides
How Diff Algorithms Work
Every diff tool answers one question: what is the smallest set of edits that turns one text into another? Here's the idea behind LCS and the Myers algorithm.
Line Diff vs Word Diff: When to Use Each
The same change can be shown as whole swapped lines or as a few highlighted words. Here's why both granularities exist and when each one is clearer.
Comparing Config Files Safely
Config drift causes real outages. Here's how to diff configuration files so you catch the meaningful change without leaking secrets or drowning in noise.