gitignore

What this is. A file called .gitignore lists things git should pretend it cannot see. Each line is a pattern, and matching files never appear as untracked and can never be committed by accident.

`

node_modules/

.DS_Store

*.log

secrets.env

.venv/

`

Four categories belong in it, and knowing why matters more than memorizing a list.

Secrets. API keys, passwords, anything in a .env file. A repository is often public and always shared.

Dependencies. node_modules and .venv are large, machine specific, and reproducible from a manifest. Committing them is committing tens of thousands of files nobody will read.

Generated output. Build directories can be rebuilt from source. Committing them creates conflicts on files nobody edits by hand.

Operating system noise. .DS_Store on macOS, Thumbs.db on Windows. Nobody wants your file manager's preferences.

✦ Committing a secret is genuinely hard to undo

Deleting the file in a later commit does not remove it, because the whole point of git is that history is kept. The key is still there for anyone who reads the log. The real fix is to rotate the key, treating it as compromised, and only then clean the history. This is why the ignore file comes before the first commit rather than after.

SANKOFA SANDBOX
learner:~$

The portfolio contains a .DS_Store and a secrets.env, exactly the sort of thing that should never be committed.

Try it → Run `cd portfolio`, `git init`, then `git status` and notice secrets.env and .DS_Store in the untracked list. Then create an ignore file with `echo secrets.env > .gitignore`, add `.DS_Store` to it with `>>`, and run `git status` again.

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: Commits Worth Reading →
← Back