About the Gitignore Builder
Every language and toolchain scatters its own build artifacts, caches, and local config — node_modules, __pycache__, .terraform, .DS_Store, IDE folders. This builder composes a .gitignore for your exact stack from curated per-technology blocks, so the repository starts clean instead of accumulating committed junk that must be surgically removed later.
Getting it right at repo creation matters more than it looks: files committed before the ignore rule exists stay tracked forever, and secrets committed even once live in git history until someone rewrites it.
Frequently asked questions
Why is a file still tracked after I added it to .gitignore?
.gitignore only prevents untracked files from being added — it never affects files already in the index. Remove them from tracking with git rm --cached <file> (keeps the working copy), commit, and the ignore rule applies from then on. For directories: git rm -r --cached <dir>.
Should lock files like package-lock.json be gitignored?
No — commit them. Lock files are what make installs reproducible across machines and CI; ignoring them reintroduces "works on my machine" dependency drift. The artifacts to ignore are the installed outputs (node_modules, .venv, vendor), never the lock files that describe them.
What belongs in the repo .gitignore versus my global one?
Project-generated files (build output, caches, local env files) belong in the repo's .gitignore so every contributor benefits. Personal-environment noise — .DS_Store, Thumbs.db, your editor's swap files — belongs in your global ignore (git config core.excludesFile), keeping project files free of every contributor's OS and editor specifics.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.