.gitignore Generator
Select the languages, frameworks, editors, and operating systems in your project to build a combined, deduplicated .gitignore file.
Select one or more stacks above to build your .gitignore. Shared patterns are included only once.
Everything is generated locally in your browser — nothing is uploaded.
How it works
- Click the chips for every stack your project uses — for example Node, macOS, and VS Code — or narrow the list with the search box first.
- Watch the combined .gitignore build live in the preview, with one commented section per stack and duplicate patterns removed automatically.
- Click Copy to paste it into an existing file, or Download .gitignore to save it and drop it in the root of your repository.
Frequently asked questions
- How does the generator combine multiple stacks?
- Each stack you select contributes a curated block of ignore patterns under its own comment header, in a stable order. Before a pattern is added, the generator checks whether an earlier section already emitted the exact same line — so shared entries like build/ or *.log appear only once, keeping the file short and easy to review.
- Where do I put the .gitignore file and when does it take effect?
- Place it in the root of your repository (the same folder as the .git directory) and commit it like any other file. Git applies it immediately to untracked files. You can also keep additional .gitignore files in subdirectories; their rules apply relative to that folder.
- Why are some files still tracked after I add the .gitignore?
- A .gitignore only prevents untracked files from being added — it never removes files Git already tracks. To stop tracking something that was committed earlier, run git rm --cached <file> (or -r for folders), commit the change, and from then on the ignore rule applies.
- Is anything uploaded when I generate the file?
- No. The pattern lists for all 20 stacks are embedded in the page itself, and the combining, deduplication, copy, and download all happen with JavaScript in your browser. Nothing about your project or your selections is sent to any server.
- Which stacks are covered, and can I edit the result?
- The generator covers Node, Python, Java, Go, Rust, C++, Unity, Godot, Android, iOS/Swift, Flutter, Rails, Laravel, and WordPress, plus macOS, Windows, Linux, JetBrains IDEs, VS Code, and Vim. The output is plain text, so you can freely add project-specific rules or delete lines after copying or downloading it.
About this tool
A .gitignore file tells Git which files and folders to leave out of version control: dependency directories, build output, editor state, OS metadata, and secrets like .env files. This generator builds that file for you from curated pattern sets for 20 common stacks — languages and frameworks such as Node, Python, Java, Go, Rust, C++, Flutter, Rails, and Laravel; game engines like Unity and Godot; mobile targets for Android and iOS/Swift; and the environment layer of macOS, Windows, Linux, JetBrains IDEs, VS Code, and Vim. Real projects almost always need several of these at once, which is exactly what the multi-select is for.
Everything runs client-side. The pattern lists ship inside the page, and selecting chips simply merges them in your browser — there is no request to a template API and no record of what you generate. The merge is deduplicating: when two stacks share a pattern, such as build/ appearing in both Node and Java, the line is written once under the first section and skipped afterwards. Each remaining section keeps a comment header naming its stack, so six months from now you can still tell why a rule exists.
Typical uses: starting a new repository and wanting a sensible ignore file before the first commit; adding a platform section (macOS Thumbs.db and .DS_Store noise is the classic offender) to an existing project; or standardizing .gitignore files across a team that mixes editors and operating systems.
Two practical tips. First, always select your operating system and editor alongside your language — .DS_Store and .idea/ pollute repositories far more often than build artifacts do. Second, if files you now want ignored were committed before the rule existed, run git rm --cached on them once; the generated rules only stop Git from picking up new files, they never rewrite history.