.gitignore Generator

What this tool does

It assembles a .gitignore from the stacks you select. Node, Python, Go, Rust, Java, the common frameworks on top of them, plus editor and operating system noise. The output is ordered, commented and safe to paste into the root of a repository.

It is aimed at the moment you start a project, when the cost of getting this wrong is nearly zero and five minutes later it is not.

Interpreting the output: a worked example

Say the generator gives you these four lines for a Python API:

__pycache__/
*.log
.env
!.env.example

Here is what each one does, and where people get caught out.

__pycache__/ — the trailing slash means directories only. A file named __pycache__ would still be tracked. This is what you want; without the slash the pattern is looser than intended.

*.log — matches at every depth, in the root and in backend/logs/app.log alike, because the pattern contains no slash. Patterns with a slash in the middle, such as logs/app.log, are anchored to the directory the .gitignore sits in.

.env — the line that matters most. Note it does not match .env.production or .env.local. If you keep per-environment files, you need .env* and then an exception.

!.env.example — a negation, so the template file stays tracked while the real one does not. Negations have one hard limit: you cannot re-include a file if its parent directory is excluded. secrets/ followed by !secrets/README.md does nothing, because git never descends into an ignored directory in the first place. Exclude secrets/* instead, then negate the file.

The rule that surprises most people is the last one, and it is stated plainly in the official gitignore documentation.

The method

Git evaluates patterns in order and the last matching pattern wins. That is why the generator puts broad exclusions first and narrow exceptions after them. It also means a .gitignore in a subdirectory overrides the root one for files beneath it.

The category templates draw on the same conventions as GitHub's public gitignore template collection, which is the de facto reference set most tooling has standardised on.

Where to put the rules

Your personal editor preferences belong in the global file, not in the project's. Adding .idea/ to a repository where nobody else uses that editor is clutter someone will eventually have to reason about.

Common mistakes

Adding a rule after the file is already tracked. .gitignore only affects untracked files. If .env is already in the index, ignoring it changes nothing. Run git rm --cached .env, commit that, and only then does the rule take effect.

Assuming a removed secret is gone. Deleting a key in a later commit leaves it in history, and on a public repository it should be treated as compromised from the moment it was pushed. Rotate it. There is no cleanup that makes this untrue.

Ignoring lock files. package-lock.json, poetry.lock and Cargo.lock should be committed. They are what makes an install reproducible.

Ignoring a whole directory that contains one file you need. Covered above — use dir/* plus a negation, never dir/ plus a negation.

Trailing spaces. A pattern ending in an accidental space will not match what you expect unless the space is escaped.

FAQ

Does .gitignore remove files that are already committed?

No. It only stops untracked files being added. Untrack the file first with git rm --cached <file>, commit, and the rule applies from then on. The file stays on your disk.

Can I have more than one .gitignore in a repository?

Yes, and it is often the tidier option in a monorepo. Rules in a subdirectory's file apply to that directory and everything below it, and they override the root file where the two disagree.

How do I keep my editor's files out of every project without adding them to each repo?

Set a global ignore file with git config --global core.excludesFile ~/.gitignore_global and put .DS_Store, .idea/ and similar in there. It applies to every repository on your machine and never gets committed anywhere.

Should I ignore the .env file or commit an example?

Both. Ignore the real .env and commit a .env.example listing every variable name with placeholder values, so a new developer knows what they need to set. Documenting that list separately is what the .env Manager is for.

What if I need to check why a file is being ignored?

git check-ignore -v <path> prints the file and line number of the pattern that matched. It is the fastest way to settle an argument with your own configuration.

Next step

Secret handling in a deployed automation is a bigger problem than one file in a repository — environment variables, a managed secrets store and a deployment that does not print them into logs. The same thinking applies to any backend you put behind a webhook, which is covered in Python FastAPI webhook automation.

If you would rather have the whole thing built and hardened for you, my automation and backend services are on Upwork.