Writing a .gitignore that keeps your repository clean
A .gitignore file tells Git which files never belong in version control: installed dependencies, build output, logs, editor settings, operating-system clutter and, most importantly, local secrets. Without one, a single git add . can commit hundreds of megabytes of node_modules or a .env file with passwords.
Pick the languages, tools and operating systems you use, and this generator combines ready-made sections into one file you can drop into the root of your repository.
How to use it
- Select every template that applies, for example Node, macOS and your editor.
- Read the combined file; each template has its own commented section.
- Copy it into a file named .gitignore in the root of your repository.
- Add project-specific lines at the end, such as a local data folder.
Example: a Node project on a Mac
Templates: Node, macOS
# Node node_modules/ npm-debug.log* … # macOS .DS_Store .AppleDouble …
The Node section keeps dependencies and build output out of Git; the macOS section keeps Finder's hidden .DS_Store files out.
How the patterns work
Each line is a pattern. A name like .DS_Store matches that file in any folder. A trailing slash, as in node_modules/, matches only directories. A leading slash, /build, matches only at the repository root. An asterisk matches anything within a name, so *.log ignores every log file, and two asterisks match across folders, as in **/tmp. A line starting with ! re-includes something an earlier line excluded, and # starts a comment.
Already committed? Ignoring is not enough
A .gitignore only affects files Git is not tracking yet. If a file was committed before you added the rule, Git keeps tracking it. Remove it from the index with git rm --cached path/to/file, commit, and from then on the rule applies. If the file contained a secret, rotate the secret: it is still in the history and in every clone.
Project rules versus personal rules
The repository's .gitignore should cover what every contributor produces: dependencies, build output, test coverage. Clutter from your own setup, such as a particular editor or operating system, can instead go in a global ignore file configured with git config --global core.excludesFile, so every repository on your machine benefits. Including common OS and editor entries in the project file anyway is a pragmatic default for teams.
Questions
Should I ignore .env files?
Yes. Commit a .env.example with the variable names and dummy values, and keep the real .env out of Git.
Should package-lock.json be ignored?
No. Lock files make installs reproducible and belong in version control, for npm, pnpm, Yarn, Cargo and Poetry alike.
How do I check why a file is ignored?
Run git check-ignore -v path/to/file. It prints the rule and the file it comes from.