diff

What it does

diff compares two files (or, with -r, two directory trees) line by line and reports the differences needed to turn the first into the second. Its output can be a raw, terse listing of changed line ranges, or — far more commonly — a unified diff (-u) showing a few lines of surrounding context with +/- markers. Unified diffs are the standard input format for patch and the format git itself uses when showing changes.

Beginner examples

• diff file1.txt file2.txt — show differences in default (terse) format
• diff -u file1.txt file2.txt — show differences in unified (patch-style) format
• diff -q file1.txt file2.txt — just report whether the files differ, no details
• diff -i file1.txt file2.txt — compare while ignoring case

diff -u server.conf.bak server.conf

Advanced examples

• Compare two entire directory trees recursively: diff -r site-old/ site-new/
• Generate a patch file that patch can later apply: diff -u orig.c fixed.c > fixed.patch
• Ignore whitespace-only changes when reviewing a reformatted file: diff -w before.py after.py
• Compare directories while treating missing files as empty (helps see additions cleanly): diff -rN dir1/ dir2/
• Show only which files differ across two directory trees without full detail: diff -rq build-old/ build-new/

diff -u <(sort file1.txt) <(sort file2.txt)

Common mistakes

• Reading raw (non-unified) diff output and finding it cryptic — the a/c/d notation is much harder to parse than unified format; use -u almost always.
• Comparing files that are logically the same but formatted differently (line endings, trailing whitespace) and getting a huge, noisy diff — use -w or -b to filter that out.
• Forgetting -r when trying to diff two directories, which causes diff to only report "Common subdirectories" without descending into them.
• Assuming diff output order tells you what changed "from" and "to" — always double check which file was passed first vs. second, since that determines the direction of +/-.

Tips

• Use process substitution to diff the sorted or filtered output of two commands without writing temp files: diff <(sort a.txt) <(sort b.txt).
• diff -y shows a side-by-side comparison, which can be easier to read for short files than inline unified output.
• When you only care about whether two files are byte-identical (not what changed), cmp -s is faster than diff -q for that specific check.

Best practices

• Always generate patches with -u (unified format) — it's smaller, more readable, and the format patch/git apply expect by default.
• When diffing config files before a deploy, combine -u with -w to filter noise from whitespace-only reformatting and focus on substantive changes.
• For directory comparisons in CI or release checks, use diff -rq first to get a quick list of changed files before drilling into individual diffs with -u.

Real-world use cases

• Reviewing what changed in a config file before restarting a service: diff -u nginx.conf.bak nginx.conf.
• Producing a patch to share a fix with a team that doesn't use the same version control system: diff -u broken.py fixed.py > fix.patch.
• Verifying a deployment matches source by diffing an extracted release directory against the repository: diff -rq repo/dist/ /var/www/app/.

Common interview questions

• Why is unified diff format (-u) preferred over the default format? It shows surrounding context with clear +/- line markers, is far more readable, and is the format expected by patch and git apply.
• How do you compare two directories recursively? diff -r dir1/ dir2/ — it descends into subdirectories and compares files with matching names on both sides.
• What's the difference between diff and cmp? diff shows a line-by-line textual comparison suited to text files; cmp does a byte-by-byte comparison and reports the first differing byte, making it more suitable for binary files or a fast identical/ not-identical check.