.gitignore: files git should never touch

Not everything in your project folder deserves to be photographed. A .env file holding your database password. A debug.log that grows every time you run the app. A node_modules folder with ten thousand files that can be rebuilt any time from a list. These files are real, they sit on your disk, and git would happily photograph them — because git cannot tell a password from a poem.

The trouble is what happens after. A file committed once is in the album forever, and history is supposed to be permanent. Commit your password and it sits in the record even after you delete it from the latest version — anyone with the history can find it. Teams have leaked secrets exactly this way. The cure is simple and cheap: teach git the rules before the first photograph, not after.

The rules live in one file in the top of your project, named exactly .gitignore — the dot matters. Inside it, one pattern per line. Blank lines and lines starting with # are ignored, so you can leave yourself notes.

Each pattern matches against file names. *.log — a star means anything — matches every file whose name ends in .log. A plain name like .env matches only that exact file, anywhere in the project. A folder name like node_modules/ ignores that entire folder and everything inside it.

The .gitignore file itself is an ordinary file, and it should be committed like one. That feels backwards until you think about who reads it: not just you, but anyone who clones your project — a teammate, future-you on a new computer, a stranger on GitHub. A committed .gitignore means the rules travel with the project automatically.

Watch what happens in the practice below: create .gitignore with *.log inside it, then create debug.log — and notice that status does not mention it at all. The file exists on disk, but to git it has become invisible. That invisibility is the whole feature.