.gitignore Generator

A .gitignore file tells Git which files to leave untracked: dependencies that can be reinstalled, build output, logs, editor settings and, most importantly, secrets. Starting a repository without one is how node_modules folders and .env files end up in commit history. This generator combines ready templates for the languages, frameworks, systems and editors in your project into one file, and lets you test paths against it.

How patterns work

Each line is a pattern. A plain name such as node_modules/ matches a folder of that name anywhere in the repository; the trailing slash limits it to folders. A pattern with a slash at the start or in the middle, such as /build or docs/*.pdf, is anchored to the folder containing the .gitignore. * matches anything except a slash, **/ matches any number of folders, and a leading ! re-includes something an earlier line ignored. When several lines match, the last one wins.

The templates

Language templates cover dependency folders, caches and compiled files for Node.js, Python, Java, Go, Rust, .NET, PHP, Ruby and Swift. Framework templates add the output of Next.js, Astro and Vite, Django, Laravel, Android, Flutter and Unity. Tool templates handle Terraform state, Docker overrides, logs and secrets. Operating-system templates catch .DS_Store, Thumbs.db and similar files, and editor templates handle VS Code, JetBrains IDEs and Vim swap files.

Merging without duplicates

Many templates share lines; build/ or *.log appear in several. The generator writes each template under a heading in the order you picked them and drops any line that an earlier section already contains, so the result stays short and readable. Patterns you type in the “your own patterns” box are added at the end under a Project heading.

Secrets and lockfiles

The secrets template ignores .env and every .env.* file, then re-includes .env.example with !.env.example, so the template of variable names can be committed while real values cannot. Lockfiles such as package-lock.json, pnpm-lock.yaml and poetry.lock are deliberately not ignored: committing them is what makes installs reproducible. The Flutter template is the exception: it ignores pubspec.lock, which suits packages, but Dart recommends committing the lockfile for apps, so delete that line in an app project.

A worked example

The “Sample: Next.js app” button picks Node.js, Next.js, secrets, logs, macOS, Windows, VS Code and JetBrains. The file starts with # Node.js and node_modules/, includes a # Next.js section with .next/ and next-env.d.ts, contains !.env.example, and lists .DS_Store exactly once even though it could come from several places: 68 lines in all. Testing the path web/.next/cache/x.json reports that it is ignored by the rule .next/.

Testing paths

Type a path in the tester to see whether the current patterns ignore it and which line decides. End a path with a slash to test it as a folder. For the definitive answer in a real repository, git check-ignore -v path prints the file and line of the matching rule.

What a .gitignore cannot do

It only affects untracked files. If a file is already committed, ignoring it changes nothing until you run git rm --cached on it. Git also never looks inside an ignored folder, so a ! rule cannot re-include a file whose parent folder is ignored; ignore folder/* instead of folder/ if you need exceptions inside it.

Related tools

• Git Command Finder has recipes for untracking files and cleaning history.
• Dockerfile Generator writes a matching .dockerignore.
• .env Converter handles the variables you keep out of Git.
• Conventional Commit Builder writes the commit that adds the file.