Git Diff
A Git diff shows, line by line, what has changed between two versions of a file. It is the standard form in which programmers review, discuss, and share changes.
Many people often work on a program at the same time. So that nothing gets lost in the process, every version of the program text is saved. This is handled by a piece of software called Git, which manages the complete history of a project. A Git diff is the answer to the question: What exactly is different between two of these versions? What is output is not flowing text, but a list of the affected lines. Removed lines are prefixed with a minus sign, newly added ones with a plus sign.
Why programmers think in diffs
A medium-sized software project consists of hundreds of thousands of lines of text. Nobody can read through all of that anew after every change. Almost always, what is interesting is only the difference from the previous version. The diff reduces a huge amount of data down to the handful of lines that actually matter.
That’s why the diff is also the foundation of quality control. Before a change is incorporated into a project, at least one other person looks it over. This process is called code review, and during it the person reads nothing other than a diff. Errors are caught this way before they reach users.
One side effect is traceability over the years. If a bug appears, it is possible to trace back which individual change caused it. Instead of searching through the entire file, one goes through the diffs of the past weeks. In companies, this is often also a legal requirement: it must be documented who changed what and when.
Plus, minus, and the surrounding context
Git compares two versions of a text and looks for the longest common sequence of lines. Everything missing from that sequence is considered deleted or inserted. The result is output in blocks, so-called hunks. Each hunk begins with an indication of which line number it applies to.
Around every change, three unchanged lines are shown by default. This context serves as orientation, since a bare line without its surroundings says little. A common misconception is that a diff stores the change itself. In fact, Git stores complete file versions; the diff is recalculated whenever needed.
It is also important to know what a diff cannot do. It works line by line and purely on the text level. If someone moves a section of a program to another location without changing it, the diff sees one large deletion and one large insertion. And with images or videos it fails entirely: there, Git only reports that the file has changed.
From the terminal to the AI assistant
The most direct way to encounter diffs is via the git diff command on the command line. They are more visible on platforms like GitHub or GitLab, which host millions of software projects. There, every proposed change appears as a color-coded comparison: deleted lines in red, new ones in green. Wikipedia also uses the same principle in its version history.
In recent years, the diff has also become a format for communication between humans and machines. AI programming assistants usually output their suggestions as a diff rather than as a complete new file. The user then sees exactly which lines the assistant wants to touch, and can accept or reject individual suggestions.
Diffs also play a role in training such systems. Public projects contain millions of documented changes along with brief justifications. From these, models learn what a sensible correction looks like. Anyone reading news about programming AI will therefore regularly come across this term.