What is the most important thing to gitignore?

Secrets. A committed .env file or credentials are the most common and most damaging git mistake - once pushed, they are in the history forever and bots scrape public repos for exactly this within minutes. Always ignore .env and credential files before your first commit. If something secret was already committed, rotate it immediately; removing it from a later commit does not remove it from history.

gitignore or dockerignore?

Both, for different jobs. .gitignore controls what gets committed to version control; .dockerignore controls what enters your Docker image build. They overlap on secrets and build artifacts, but .dockerignore also excludes things you do commit but do not want in the image, like the .git directory and tests.

Should I commit lock files?

Yes - commit package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock for applications, poetry.lock, and so on. Lock files pin exact dependency versions so every install is reproducible. Ignore the installed dependency directories like node_modules and .venv but keep the lock files.

Free tool · Runs in your browser

.gitignore, done right.

The most damaging git mistake is committing a .env — once pushed, the secret is in history forever, and bots find it in minutes. Pick your stack and get a .gitignore that keeps secrets, dependencies, build output, and editor junk out of version control.

Stack

Ignore secrets & .env (essential) Ignore editor / OS junk Ignore logs & temp files

The commit you can’t take back

Git history is permanent by design, which is wonderful for code and terrible for secrets. The moment a .env or a key is pushed to a remote, it is effectively public — deleting it in a later commit leaves it sitting in history, and automated scanners crawl public repos for credentials constantly. A correct .gitignore, in place before your first commit, is the cheap insurance against the single most common way developers leak production secrets.

Keeping secrets out of git is one habit in a larger discipline: secrets belong in a controlled, auditable place, not scattered through repos, configs, and chat. Managing that across the backend you own is part of what a control plane is for.

Related free tools

Deploy to your own serverPush-to-deploy, your box systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS DNS records helperPoint your domain

All free tools →

Secrets out of git, into a vault.

Infraveil runs your backend on servers you own with secrets managed and access audited — one controlled place for credentials, not a trail through your git history.

See how it works

Get the secure-build playbook

Secrets, ignore files, and repo hygiene for a backend you run yourself. No spam.