Gitignore Generator

How to use Gitignore Generator

1. Pick your language, framework and editor.
2. Review the generated rules and add anything specific to your project.
3. Save it as .gitignore at the repository root, before the first commit if you can.
4. Already-tracked files are unaffected — use git rm –cached to untrack them.
5. Commit your lock files; ignoring them defeats the purpose of having them.
6. Put OS and editor noise in a global excludesfile rather than the project’s ignore.

Ignoring a file does not remove it from history

This is the mistake that matters. Adding a path to .gitignore only stops Git tracking it from now on — a file already committed stays tracked, and stays in every previous commit forever. git rm --cached untracks it going forward and leaves the history intact. To remove something from history entirely you need git-filter-repo or BFG, and a force-push that rewrites every commit hash and breaks everyone’s clone. Which is why the only real answer for a committed secret is to rotate it.

The three categories worth ignoring

Dependencies that a manifest can reconstruct: node_modules, vendor, venv. Build output: dist, build, target, .next. And machine-specific files: .env, .DS_Store, .idea, editor swap files. The principle is that anything reproducible from what is committed, or specific to one developer’s machine, does not belong in the repository. Committing node_modules is the classic beginner error and makes every clone enormous and every diff unreadable.

Editor and OS files belong in a global ignore

Your .DS_Store and .idea/ are your problem, not the project’s — a colleague on Linux using Vim should not have to carry them in the repository’s ignore file. Configure a personal global gitignore with git config --global core.excludesfile and put OS and editor noise there once. The project’s .gitignore then covers only what the project genuinely produces, which keeps it short and reviewable.

Lock files are the exception people get wrong

package-lock.json, yarn.lock, Gemfile.lock, poetry.lock and Cargo.lock should be committed, not ignored. They pin exact dependency versions so that every developer and every CI run installs identical trees — which is the entire point of having them. The one debated case is a published library rather than an application, where some maintainers omit the lock file so consumers resolve their own versions.