some files never leave your computer.

Every commit saves a snapshot of your project, and every push sends it to GitHub. One small file decides what is left out of that snapshot: .gitignore, in the top folder of your copy. It keeps your keys on your computer, skips the tools anyone can download again, and leaves out the files your site rebuilds by itself. Your copy arrived with it already set up. This step is about reading it, so you always know what you are sending.

Left out	Why
.env	Your keys and passwords. Only .env.example, the empty template, is saved
node_modules	The tools npm ci downloads. Anyone can download them again
.next	What npm run dev and npm run build make. Rebuilt every time
Files ending in .log	Crash and debug logs. They can hold details from your computer
Generated lists	Files the build makes again on every run (the rule below)

Left out: .env
Why: Your keys and passwords. Only .env.example, the empty template, is saved

this is a work in progress

Read.
Open your .gitignore.
Check.
Ask git about one file.
Untrack.
Stop saving a file git already has.

Read.
Open your .gitignore.

Success.git tells you which line keeps .env off GitHub.

Your copy on your computer — from Get your copy
A .env file — from Create your database, so there is something worth keeping private

1️⃣ Read Your .gitignore

Open .gitignore in your editor. If you cannot see it, your computer is hiding files that start with a dot: on a Mac, press Cmd + Shift + . in Finder. Each line is a pattern, and git leaves out every file that matches one. Lines that start with # are notes for people.

bash

# env files: secrets stay on your computer (.env.example is the template)
.env*
!.env.example

A star means anything — .env* matches .env, .env.local and .env.backup alike
An exclamation mark means except — !.env.example brings the template back, so the next person knows which keys to fill in
A slash at the start means only the top folder — /node_modules is the one next to package.json

2️⃣ Ask Git About One File

You never have to guess. Open Terminal in your project folder (in GitHub Desktop: Repository → Open in Terminal) and ask about any file:

bash

git check-ignore -v .env

.gitignore:47:.env*	.env

If it prints nothing, git will save that file. GitHub Desktop shows the same thing another way: an ignored file never appears in the Changes list, no matter how often you edit it. To leave out a new file, right-click it in Changes and choose Ignore file, which adds its line to .gitignore for you.

3️⃣ The One Rule for Files Your Site Makes

Some files are written by your site's own scripts, not by you: lists of your icons and images, the colors of each cover, which stories mention which project. Each of them follows one rule, written at the top of your .gitignore:

“Save a generated file only when it can't be made again.”
— unparty-app

File	Made by	Saved?
Icon and image lists	Every build	No: the build makes them again
Cover colors	A tool that only runs on a Mac	Yes: Vercel cannot make them
Video details	ffprobe, which not every computer has	Yes
Cover file types	Every build, but pages read it right away	Yes: a fresh copy needs it before its first build

File: Icon and image lists
Made by: Every build
Saved?: No: the build makes them again

Saving a file the build makes again is not harmless. It changes on every run, so it shows up in every change you review, and two changes to it clash with each other. Leaving out a file the build can't make breaks your site the first time it is built somewhere new.

🧹 Adding a Line Is Not Enough

A line in .gitignore only stops git from picking up new files. A file git already saves keeps being saved with every commit, line or no line. To stop saving it, tell git to forget it while leaving it on your computer:

bash

git rm --cached src/data/iconManifest.json
git check-ignore -v src/data/iconManifest.json

GitHub Desktop now lists the file as deleted. Commit that. The file stays on your computer, git stops saving it, and on every other computer the next pull removes it until a build makes it again. This copy had exactly this problem: two lists sat in .gitignore for seven months and were still saved in seven more commits.

⚠️ What .gitignore Cannot Do

It cannot take back the past — a file saved before its line was added stays in your history, and anyone with access to your repository can still read that old version
If a key ever reached GitHub, replace the key — make a new one where you got it (Neon, Clerk, Polar…) and put it in .env. Deleting the file afterwards is not enough
Keep the name .env — .env.backup is still left out, but env.txt or keys.env.txt is saved like any other file
Never delete the .env lines — they are the only thing between your keys and GitHub

🧯 If Something Is Off

.env shows up in GitHub Desktop — do not commit. Check the name has nothing after env except a dot and a word, and that the .env lines are still in .gitignore
A file keeps coming back after you ignored it — git already saved it. Run git rm --cached on it, then commit
A page breaks after you ignored a generated file — the site needs it before any build. Take its line back out of .gitignore and commit the file again

🤖 Ask Your LLM

prompt

Here is my .gitignore: [paste it]. Explain each line in plain
words, and tell me if anything private could still be saved.

A script in my project writes this file: [file name]. Is it
made by every build, or only on some computers? Should it be
saved in git or added to .gitignore?

I think I committed a key by mistake. Here is the file name
(not the key): [file name]. Walk me through replacing the key
and stopping git from saving that file.

✅ You Are Done When

git check-ignore -v .env prints the .gitignore line that protects it
.env has never appeared in GitHub Desktop's Changes list
You can say whether a new generated file belongs in git or in .gitignore, and why

Next, let your computer check your work as you go: Local guardrails turns on the checks that run each time you commit and push.

“Know what you send before you send it.”
— unparty-app