From Terminal to Gutter
For most of the 1990s, version control was a discipline practiced outside the editor. CVS — the Concurrent Versions System — lived on the command line, and a developer who wanted to inspect a diff closed the source file, opened a terminal, and read unified diff output in monochrome text. The editor held the code; the revision history lived somewhere else entirely.
Eclipse changed the geometry. When IBM released Eclipse in November 2001 and donated it to an open-source consortium (later the Eclipse Foundation), the plugin architecture was open enough that CVS support shipped in the core distribution from the first public release. The Team menu offered update, commit and synchronize operations without leaving the IDE. Diff results appeared in a dedicated compare editor — two panes, side by side, navigable by keyboard. It was still a separate view rather than an annotation on the code itself, but the conceptual break had been made: version control was now an IDE concern.
The gutter annotation — the coloured bar in the margin that marks a changed, added or deleted line — came later, and it came from the Subversion era. SVN clients embedded in Eclipse and later in NetBeans began marking modified lines with narrow coloured strips in the editor margin. A developer could see, at a glance, which lines had moved since the last commit without switching panes at all. The diff had entered peripheral vision.
Git's adoption across the industry in the late 2000s and early 2010s accelerated the integration considerably, because Git made staging granular. Selecting a hunk — a contiguous block of changed lines — rather than an entire file demanded a UI that could represent that granularity. JetBrains, whose IntelliJ IDEA had been pushing IDE-level version-control awareness since the early 2000s, built hunk-level staging into its Git tooling. A developer could right-click a gutter annotation, stage that hunk alone and leave adjacent changes unstaged.
Inline blame — the annotation that shows, for each line, the commit hash and author responsible — became the final gesture of full integration. Git blame had existed as a command-line operation since Git's early years, but surfacing it as a hover tooltip or a persistent gutter label, selectable per-line, required editor APIs that matured through the early 2010s. Visual Studio Code, shipping in 2015 with a Git integration built into the sidebar and GitLens available through its marketplace, made inline blame a routine expectation rather than an advanced feature.
What the terminal once held exclusively — the diff, the blame, the staged hunk — had by the mid-2010s become part of the editor's own surface, as assumed as syntax highlighting.