.gitignore — what shouldn't be tracked at all

Some files are secrets — API keys, database passwords, tokens — that should never end up in Git's history at all, since the earlier lessons in this domain established that history is permanent and shared the moment it's pushed to a remote. Others are regenerable build artifacts — compiled files, dependency folders, cache directories — that add no real value to version control and just bloat the repository with files that get recreated automatically anyway. Both categories are what .gitignore exists to keep out.

.gitignore is a plain text file, one pattern per line, placed at the root of the repository — any file or folder matching a pattern in it is excluded from git status, git add ., and everything else that would normally pick up new files. *.pyc uses a wildcard to match any file with that extension, anywhere; a trailing / (node_modules/) specifically matches a directory. Once a pattern is in .gitignore, Git stops surfacing matching files as "untracked" entirely — they become invisible to the normal workflow from the daily-workflow lesson.

This is a genuinely common, real mistake: adding a pattern to .gitignore only prevents Git from picking up files it doesn't already know about — it has no effect on a file that was already git added and committed before the ignore rule existed. If a secret was accidentally committed once, adding it to .gitignore afterward stops future changes to that file from being tracked, but the secret is still sitting in the commit history from before, fully readable by anyone who can see that history.

git rm --cached removes a file from Git's tracking without deleting it from the working directory — the file stays on disk, exactly as it was, but a new commit records that it's no longer tracked going forward. This handles "stop tracking this file from now on" — but it does not remove the file from earlier commits already in history; a secret that was committed once is still recoverable from that earlier commit, permanently, unless the history itself is rewritten (a genuinely more advanced, disruptive operation, and the real reason "just add it to .gitignore after the fact" is not a real fix for a leaked secret).

Regenerable build artifacts (compiled output, installed dependencies, cache files) cause real, ongoing problems if committed — they bloat every future clone, generate noisy diffs unrelated to actual code changes, and can even conflict with a teammate's independently-regenerated version of the same files. The rule of thumb: if a file can be regenerated automatically from something else that is tracked (a package.json, a requirements.txt), it usually belongs in .gitignore, not in the repository itself.

Rather than writing a .gitignore from scratch for every new project, GitHub maintains a large collection of standard, language/framework-specific templates (a Python one covers __pycache__/, .pyc files, virtual environments; a Node one covers node_modules/, build output) — starting from one of these and adding project-specific entries on top is the normal, practical way most .gitignore files actually get created.