Learn how diff algorithms work, integrate git diff into your workflow, resolve merge conflicts, and choose the right visual diff tools for comparing code and documents.
I spent an entire afternoon debugging a production issue. The code looked identical to what was working yesterday. Turns out, someone had changed a single character deep in a config file. If I'd run a diff first, I would have found it in seconds.
Now I diff everything. Pull requests, config files, deployment artifacts. Understanding diff output is one of those fundamental skills that just keeps paying off.
Unified diff is what git shows you. Once you can read it fluently, code reviews get much faster.
Here are the git diff variations I actually use, not just the ones in the docs:
I used to dread merge conflicts. Now I see them as git asking me to make a decision it could not make automatically. That is actually reasonable.
These config options made my daily diff experience much better:
Sometimes the terminal is not enough. Here is what I use:
The best conflict is the one that never happens. These habits reduce conflict frequency:
Diff is not just for code. I use it for all kinds of comparisons:
Learn to read diffs fluently. Configure git diff the way you like it. Use visual tools when they help. The time you invest in mastering diff pays back every single day.
Start with git diff basics, then gradually explore the options as you need them. And when you need a quick comparison, the Diff Checker on this site works without any setup.
Regular diff compares any two files. Git diff is git-aware - it knows about commits, branches, staging area, and integrates with your repo history. Use git diff --no-index when you want git diff features on files outside a repo.
Find the conflict markers (<<<<<<, ======, >>>>>>), understand what both versions are trying to do, combine them intelligently, delete all markers, then git add and commit. Always test after resolving.
For code, use histogram: git config --global diff.algorithm histogram. It handles moved blocks better than the default. You will notice the difference in refactoring PRs.
git diff -w ignores all whitespace. git diff -b ignores changes in amount of whitespace. Essential when someone ran a formatter on a file.
git diff main..feature shows all differences. git diff main...feature (three dots) shows only what feature added since it branched off. The three dots version is usually what you want for PR reviews.
Depends on your needs. VS Code built-in is good for most things. Meld for complex three-way merges. delta for terminal with syntax highlighting. For quick web-based comparison, use the Diff Checker on this site.
Founder of CodeUtil. Web developer building tools I actually use. When I'm not coding, I experiment with productivity techniques (with mixed success).
After pasting sensitive API responses into random online tools for years, I finally did a proper comparison. Here's what I actually use now and why privacy matters more than features.
After 10+ years of web development, I've tried countless tools. Here are the ones that stuck - the utilities I reach for every day to format, debug, and validate.
I used to push broken code constantly. Now my git hooks catch linting errors, run tests, and validate commits before they embarrass me. Here's my exact setup.