A .gitignore for every stack

A .gitignore file tells Git which files to leave untracked — the stuff that shouldn't live in your repo. Get it right once per project and you avoid two classic messes: leaking secrets, and bloating your repo with generated junk. On Falix there's a third reason it matters, and it's the sharpest one. This guide gives you a copy-paste block per stack and explains every line.

Three kinds of file you always ignore

Whatever the language, the files you keep out of Git fall into three buckets:

Why it matters double on Falix

Falix deploys copy files from your repo and overwrite server files with the same name (they never delete files that aren't in the repo). That rule turns two ignore-mistakes into real damage:

• Commit .env and every deploy overwrites your server's real secrets with whatever placeholder is in the repo — your bot goes offline with an "invalid token" error that looks like a bad token but is really a clobbered file.
• Commit node_modules (or vendor, target) and you ship a heavy, machine-specific folder over the one the server builds for itself — the Node and Python apps run npm install / pip install on every start anyway, so the repo copy is pure downside.

Ignore both from day one and your secrets and dependencies stay exactly where they belong: on the server, rebuilt or preserved, never overwritten. (More on the copy-only model in Keep secrets out of Git.)

🎯 Good to know: .gitignore only stops files Git isn't already tracking. If you committed .env before ignoring it, you must untrack it too — and rotate any secret that was in it, because a pushed secret is a leaked secret.

The blocks

Drop the matching block into a file named .gitignore at your repo root. Each ends with the universal lines every project wants.

Node.js — dependencies and build output rebuild themselves; the database and secrets stay on the server:

node_modules/
dist/
build/
*.db
.env
# editor & OS
.vscode/
.DS_Store

Bun — same shape as Node (Bun installs into node_modules too):

node_modules/
dist/
.env
.DS_Store

TypeScript (on the Node app) — also ignore the compiled output, since it's rebuilt from source:

node_modules/
dist/
*.tsbuildinfo
.env
.DS_Store

Python — __pycache__ is bytecode, .local is where Falix installs your requirements, and virtualenvs never belong in Git:

__pycache__/
*.pyc
.local/
venv/
.venv/
*.db
.env
.DS_Store

PHP (Composer / web) — vendor/ is Composer's install target and rebuilds from composer.json:

/vendor/
/tmp/
*.log
.env
.DS_Store

Go — the app runs a prebuilt binary named app; don't commit the compiled artifact when you build on deploy:

app
*.exe
bin/
.env
.DS_Store

Rust — target/ is the entire build directory and can be enormous; Cargo.lock is the one thing you keep:

/target/
.env
.DS_Store

Java — ignore the build output (target/ for Maven, build/ for Gradle) and stray class files; commit the source and your build file:

target/
build/
*.class
.env
.DS_Store

Static site (HTML/CSS/JS) — little to generate; mostly keep OS and editor cruft out:

.DS_Store
Thumbs.db
.vscode/
*.log

The line that goes in every one: .env

If you take one habit from this guide, it's this: .env is in every block for a reason. Your tokens, connection strings, and API keys go in a .env on the server, never in the repo — and because it's not in the repo, a deploy leaves it untouched while your code updates around it. Commit a .env.example with empty placeholder keys instead, so anyone cloning knows what to fill in without you leaking anything. The whole workflow is in Keep secrets out of Git.

Quick reference

Next steps

• Keep secrets out of Git
• Deploy from Git
• Build steps on deploy