An incremental build rebuilds only the parts of a project whose inputs have changed, rather than recompiling everything from scratch. The idea is as old as Make. The GNU Make manual states that “the make utility automatically determines which pieces of a large program need to be recompiled, and issues commands to recompile them.” Make does this by comparing last-modification timestamps: if a prerequisite is newer than the target that depends on it, or the target is missing, Make reruns the recipe; otherwise it leaves the up-to-date file alone.
The change ripples along a dependency chain. Edit one source file and Make sees that its object file is now stale, recompiles just that object, and then relinks the executable, without touching the dozens of other files that did not change. On a large project this is the difference between a one-second build and a multi-minute one.
Faster build tools push the same idea harder. Ninja’s manual lists “very fast (i.e., instant) incremental builds, even for very large projects” as its primary design goal, and it grew out of Chromium’s 30,000-plus-file codebase precisely to make the change-one-file case nearly instantaneous. Bazel goes further by tracking content rather than just timestamps: its documentation says it “caches all previously done work and tracks changes to both file content and build commands,” so it “knows when something needs to be rebuilt, and rebuilds only that.”
The progression from timestamps (Make) to content hashes and action tracking (Bazel) is what lets modern build systems share cached results across machines and continuous-integration runs, turning the incremental build from a single-developer convenience into a team-wide and reproducibility tool.