.gitignore and README

Files that must never be committed

Run a project for a day and junk appears: log files, build output, editor droppings, dependency folders like node_modules with 40,000 files that can be regenerated anytime. Worst of all, secrets: files like .env holding passwords and API keys. Committing a secret publishes it to everyone with repo access, forever, in history, even after you delete the file in a later commit.

The fix is a file named .gitignore at the repository root. Each line is a pattern, and matching files stop appearing as untracked:

# dependencies and build output
node_modules/
build/

# logs, any file ending in .log
*.log

# secrets
.env

# OS junk
.DS_Store

Patterns: a bare name matches that file anywhere, a trailing / means a whole folder, and * is the wildcard you know from the terminal course, *.log matches any name ending in .log. Commit the .gitignore itself, it's shared team policy.

The gotcha: .gitignore can't un-track a file

.gitignore works at one precise moment: it stops files from ever becoming tracked. A file you already committed is past that gate — Git keeps tracking it, pattern or no pattern, because ignoring it now could silently discard changes teammates rely on.

So when you add *.log to .gitignore and debug.log (committed last week) keeps showing up in git status, the fix is to remove it from tracking while leaving it on disk:

$ git rm --cached debug.log
$ git commit -m "Stop tracking debug.log"

--cached is the crucial flag: it deletes the file only from the staging area and the next commit's contents, not from your folder. (Plain git rm deletes both.) From that commit on, the .gitignore pattern applies. And remember the earlier warning: if the file was a secret, untracking it does not scrub old commits — rotate the secret.

README.md, the front page

GitHub renders a file named README.md from the repository root directly on the project's page, making it the first thing every visitor reads. It's written in Markdown, the same # headings, **bold**, code fences, and lists you've seen through this whole course.

A solid README answers, in order:

1. What is this? One or two sentences.
2. How do I run it? Exact install and start commands.
3. How do I use it? A minimal example.
4. How do I contribute? Where PRs and issues go (units 8-1 and 8-2).

For your portfolio, READMEs carry real weight: recruiters and interviewers open your repositories, and a clear README plus a tidy git log is evidence you work like a professional.