/

.gitignore Generator

Processed Client Side

Select the languages, frameworks, operating systems, and editors in your stack to assemble a clean .gitignore file.

Tech stack · 5 selected
Languages
Frameworks
Operating systems
Editors
.gitignore · 41 lines
5 templates
gitignoreLength: 514Lines: 41Size: 516 BytesCursor: 1:1

Bookmark this tool now — skip the search next time you need it.

About .gitignore Generator

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

The .gitignore Generator assembles a clean ignore file from the pieces of your actual stack. Click the languages, frameworks, operating systems, and editors you use, and the templates are combined into one file with each section clearly labelled, so you can see later why a rule is there. It covers the usual suspects — build output, dependency directories, virtual environments, OS clutter like .DS_Store and Thumbs.db, editor folders, and .env files carrying secrets. Getting this right at the start of a project is much easier than after the fact, because a file Git is already tracking keeps being tracked no matter what the ignore file says.

Key features

  • Seventeen templates across four groups: languages, frameworks, operating systems, and editors
  • Languages covered: Node, Python, Java, Go, Rust, Ruby, and PHP
  • Frameworks and tooling: Vite / React, Next.js, Django, and a dedicated dotenv block for secrets
  • Operating systems: macOS, Windows, and Linux, for the files each one scatters through a repository
  • Editors: VS Code, JetBrains IDEs, and Sublime Text
  • Each selection appears as its own labelled section, so the origin of every rule stays obvious
  • A generated header listing exactly which templates went into the file
  • Sensible default selection to start from, and a live line count as you toggle sections
  • Runs entirely in your browser — no account, no repository access, nothing uploaded

How to use it

  1. Click the chips for the languages and frameworks in your project.
  2. Add the operating systems your team actually uses — not just your own.
  3. Add the editors in use, so nobody commits their workspace folder.
  4. Read through the assembled file and check nothing you need tracked is excluded.
  5. Copy it into a file named .gitignore at the root of your repository.

Tips & common mistakes

  • Add .gitignore before the first commit. Once a file is tracked, adding a rule does nothing — you also need git rm --cached <file> to stop Git following it.
  • Include the OS and editor sections for your whole team, not just for you. A macOS .DS_Store committed by one developer is a nuisance for everyone on Windows, and the reverse is equally true.
  • Keep the dotenv block. Committed .env files are one of the most common ways credentials leak into a repository, and a public one is scraped within minutes.
  • A secret that has already been committed is not protected by adding it to .gitignore. It stays in the history, so rotate the credential and treat it as compromised.
  • Ignore build output, not lock files. package-lock.json, poetry.lock, and Cargo.lock belong in the repository — they are what makes an install reproducible.
  • The file lives at the repository root, but nested .gitignore files work too. Directory-level rules are often clearer than a long list of paths at the top.
  • Check with git status after adding the file. Anything you expected to disappear that is still listed is almost certainly already tracked.
  • Also setting up the repo’s documentation? Generate a starting point with the README Generator.

Related tools

Browse all 12 Development tools

Frequently asked questions

10

Click the chips for the languages, frameworks, operating systems, and editors you use. The templates are combined into one labelled file that you copy into a file named .gitignore at your repository root.

At the root of the repository. You can also add extra .gitignore files inside subdirectories, where rules apply to that directory and everything below it.

Because .gitignore only affects untracked files. For something Git already tracks, run git rm --cached <file> and commit that, and the ignore rule then takes effect.

Seventeen: Node, Python, Java, Go, Rust, Ruby, PHP, Vite / React, Next.js, Django, dotenv, macOS, Windows, Linux, VS Code, JetBrains, and Sublime Text.

Yes, always, and the dotenv template covers it. Committed .env files are one of the most common ways credentials end up in a repository, and public ones are scraped within minutes.

No. The value remains in the Git history and can be recovered from any clone. Rotate the credential immediately and treat it as compromised; rewriting history is a secondary step.

No. package-lock.json, yarn.lock, poetry.lock, and Cargo.lock belong in the repository — they are what makes an install reproducible for everyone else.

Because your teammates use different ones. A macOS .DS_Store or a Windows Thumbs.db committed by one person is noise in every diff for everyone else.

Run git status and look for anything you expected to be hidden. Anything still listed is almost certainly already tracked and needs git rm --cached.

No. The templates ship with the page and are assembled in your browser — no repository access, no account, and no network request.