Why these two tools

One note before starting

There's no official documentation directly comparing Dev Containers and pre-commit — for good reason: they're two independent tools, built by different teams, that don't reference each other. This module is a practical synthesis, not an official source. The goal is simply to give you a clear way to remember which of the two solves which problem, before you work with them in the modules ahead.

The problem Dev Containers solve

Scenario: you're developing a Node.js application locally. A new teammate clones the repo, installs the dependencies, and... nothing behaves like it does on your machine. After an hour of debugging, the cause turns up: they have Node 18 installed, you have Node 20, and a project dependency behaves differently depending on the version.

This is the classic "works on my machine" problem. Every developer has their own machine, with its own tool versions installed over time, often shared across several projects with different needs.

A Dev Container describes, in a file versioned alongside the code, the exact environment the project should run in: which base image, which language version, which system tools. When you open the project in that Dev Container, VS Code launches a container built from that description — the same container for you, for your teammate, and for anyone else who opens the project later. "My machine" and "your machine" literally become the same environment.

The problem pre-commit solves

Another scenario: a developer, in a hurry at the end of the day, pastes an API key into a config file to quickly test something, then runs git commit without a second thought. The secret ships into git history. Even if it's removed in the next commit, it's still visible in the history — a real security problem.

A more mundane variant: a file gets committed with trailing whitespace, or an obvious syntax error that a simple linter would have caught in a second.

pre-commit is a tool that runs a list of automated checks (called hooks) right before git accepts a commit. If a check fails — a secret detected, a syntax error, badly formatted text — the commit is rejected before it enters the history. The developer fixes it, then commits again. Nothing broken ever reaches the shared repo.

Two tools, two different moments

A simple way to keep the distinction straight:

• Dev Containers act while you work — they define the environment you write and run code in.
• pre-commit acts at the moment you commit — it checks what you're about to save into the history.

These are two complementary safety nets, not two competing options. In the modules ahead, you'll work with both separately: first opening and reading a Dev Container (modules 3 and 4), then installing pre-commit and seeing a blocked commit in practice (modules 5 and 6).