📦 .gitignore / .dockerignore Generator

Stack and combine presets for languages (Node, Python, Go, Rust, Java, PHP, Ruby), frameworks (React, Next.js, Django, Rails, Laravel), IDEs (VSCode, JetBrains, Vim) and OS (macOS, Windows, Linux) to produce a tidy .gitignore or .dockerignore in one click. Auto-deduplication, comment preservation, live preview, copy and download.

100% Free No signup Browser-only 5 languages Dark mode

📝 .gitignore (preview)

# Pick at least one preset

📖 Where people get stuck

Overlays presets for language, framework, IDE and operating system to produce a .gitignore or a .dockerignore, dropping duplicate lines while keeping comments. Everything runs in the browser. A .gitignore, however, only affects files that have yet to be added — a file Git is already tracking is not ignored no matter what you write. And this is where the most common misunderstanding lives: committing a .env and then adding it to .gitignore removes it from neither the repository nor the history. Ignoring something and making it never have happened are different things.

Case	What happens	What to do
It has no effect on files already tracked	Git stops consulting `.gitignore` for a file the moment it becomes tracked. So a `.env`, a `node_modules` or a build artifact that was committed once keeps showing up in diffs however many rules you add afterwards. And the real problem is not your working directory but the history — untracking with `git rm --cached` does not erase what past commits contain. Anyone can read it with `git log -p`, and if you have pushed, the same content also lives in forks, mirrors, CI caches and every clone. On a public repository, scanners that harvest keys mechanically will find it within minutes — the observed time from a key being published to being abused is measured in minutes.	First, untrack it: run `git rm --cached .env` and commit that together with the `.gitignore` addition (omit `--cached` and the file itself is deleted). Add `-r` for a directory. And if a secret was involved, there is exactly one remedy: rotate that key. Rewriting history with `git filter-repo` is possible, but do not make it your only measure — everyone has to re-clone, and it cannot reach other people forks or objects you have already pushed. Prevention is by far the cheapest: make a habit of reading `git status` before `git add`, and put `gitleaks` or `git-secrets` into a pre-commit hook.
Copying `.gitignore` straight into `.dockerignore`	The two share a format but not a purpose. A `.gitignore` lists what to keep out of version control; a `.dockerignore` lists what not to send in the build context. Reuse one as the other and it breaks in both directions. You exclude something the build needs — `dist/` is a correct exclusion for `.gitignore`, but it is a required directory for a Dockerfile that `COPY`s a pre-built artifact. And conversely you keep something that should have been excluded — without excluding `.git/` and `node_modules/`, the context runs to hundreds of megabytes and the build becomes visibly slower. Worse, a `node_modules` installed on the host ends up in the image, mixing in native modules built for a different platform that crash at runtime.	Write the two separately. Build the `.dockerignore` from the idea of letting through only what the image build needs and you will not go wrong — at minimum, drop *`.git`, `node_modules`, `.env`, `.log`, tests, documentation and CI configuration. Always include `.env` — if it reaches the context, `COPY . .` bakes it into the image and everyone you ship that image to can read it. Checking the effect is easy: look at the context transfer size printed at the start of `docker build` — a few megabytes or less is right. And a `.dockerignore` is only read at the root of the build context — one placed in a subdirectory is ignored**.
A pattern does not match where you thought	Small details of syntax change the meaning. A pattern without a slash, like `build`, matches a `build` at any depth. A leading slash, `/build`, matches only at the root, and a trailing slash, `build/`, matches only directories. The hardest to see is negation with `!`: if a parent directory is excluded, you cannot bring a file inside it back with `!` — Git does not descend into an excluded directory, so the rule you wrote is never even read. Put `node_modules/` and `!node_modules/mylib` next to each other and the second does nothing at all. No error and no warning appear, so it surfaces only as "I wrote it and it does not work".	When in doubt, run `git check-ignore -v <path>`. It prints, in one line, which rule on which line of which file took effect — knowing this command changes investigation time by an order of magnitude. No output means the path is not being ignored. To bring one item inside a directory back, exclude the contents rather than the directory: write `node_modules/` and then `!node_modules/mylib` and it behaves as intended. Stacking presets makes the file long, but length itself is not the problem* — the problem is a line nobody can explain, so keep project-specific lines together at the end with a comment.

Ignore settings do not live in one place. Git consults, in order, the repository .gitignore, any .gitignore in subdirectories, .git/info/exclude, and your global setting (core.excludesFile). There is a clear criterion for choosing between them: anything unnecessary for everyone on the project (build artifacts, dependency directories) belongs in the repository .gitignore, while anything specific to your own environment (editor settings, files your OS creates, personal notes) belongs in your global setting. Putting .DS_Store, Thumbs.db or .idea/ in the repository .gitignore is, strictly speaking, imposing your environment on everyone else — although in practice everyone does it, and agreeing on it as a team causes less friction. Finally, Git does not track empty directories — if you need an empty logs/ to exist, place an empty file at logs/.gitkeep (.gitkeep is not a Git feature, merely a conventional filename).

📖 How to Use

1

Pick a mode

Pick .gitignore or .dockerignore at the top. .dockerignore prioritises image-bloat patterns (node_modules / .git / *.log).
2

Pick stacks

Click chips for the languages, frameworks, IDEs and OS you use. Multi-selection merges and deduplicates them.
3

Copy or download

Copy to clipboard or download as .gitignore / .dockerignore from the buttons above the preview.

❓ Frequently Asked Questions

What is the difference between .gitignore and .dockerignore?

.gitignore excludes patterns from Git tracking. .dockerignore excludes them from the Docker build context (COPY / ADD). Same goal — different consumer. .dockerignore should especially exclude node_modules / .git / *.log to keep image size down.

Can I append to an existing .gitignore?

Yes. Copy the preview into the end of your existing file, or run something like `cat existing.gitignore generated.gitignore | sort -u > new.gitignore` to dedupe.

How is this different from github/gitignore?

github/gitignore provides exhaustive single-stack templates (100+ lines each). This tool curates the most-needed lines per stack and merges multiple stacks into one tidy file. Less verbose, faster to read.

Can you add more presets?

Send the stack name via the feedback form below. We add high-demand presets.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.