the build graph and incremental rebuilds
Picture all the files in your project as dots, with an arrow drawn from each thing to the things it is made from: the program points to its object files, each object file points to its source and headers. That web of arrows is the build graph. An incremental rebuild means: when something changes, redo only the parts of that graph that are downstream of the change, leaving everything else untouched.
Make builds this graph in its head from your rules' targets and prerequisites. To decide what is out of date, the classic technique is timestamps: every file has a last-modified time, and a target is considered up to date if it exists and is newer than all of its prerequisites. So if you edit util.c, its modified time jumps ahead of util.o; Make sees util.o is now older than util.c, rebuilds util.o, then sees app is older than the new util.o, and relinks app. main.o, whose source did not change, is left alone. That is the whole trick: walk the graph, compare timestamps, rerun only stale recipes.
Why it matters: incremental rebuilds are what make iterating on a large program bearable; you change one file and rebuild in a second instead of recompiling everything. But timestamps are a proxy, not the truth. If a clock is wrong, a file is touched without changing, or a dependency is missing from the graph, Make can wrongly skip work (a stale build) or wrongly redo it. When a build behaves strangely, a clean build from scratch is the usual reset.
Build graph: app <- main.o <- main.c ^ |--- util.o <- util.c Edit util.c -> util.o stale -> app stale. Make rebuilds util.o and relinks app; main.o is untouched.
A change ripples downstream through the graph; only the affected targets are rebuilt.
Timestamp-based up-to-date checks are a heuristic, not a guarantee. A wrong system clock, a 'touched' file, or an unlisted dependency can make Make skip needed work; this is why a clean build sometimes 'fixes' a baffling problem.