Use the .gitignore Generator to combine language, OS, IDE, and project rules, then review the result before committing it.
A .gitignore file is a version-control rule set, not a security boundary. It tells Git which untracked paths to hide from ordinary status and add operations. A good file keeps generated noise out of reviews while making sure source code, lockfiles, and deployment configuration remain visible to the team.
1. What .gitignore does
Git evaluates ignore patterns when a path is not already tracked. Ignoring a file does not delete it, encrypt it, or stop an application from reading it. If a credential was committed in an earlier revision, adding it to .gitignore does not remove it from history; revoke and rotate the credential, then clean history only with a deliberate migration.
2. Pattern rules that matter
| Pattern | Meaning |
|---|---|
node_modules/ | Ignore directories with this name |
*.log | Ignore matching files at any depth |
/dist/ | Ignore dist at repository root |
build/ | Ignore build directories in matching scopes |
!important.log | Re-include a path after a broader rule |
config/*.local | Ignore matching files in a specific directory |
A trailing slash communicates that a pattern is intended for directories. A leading slash anchors a pattern relative to the current .gitignore file. Negation is processed in order, so a parent directory ignored earlier may prevent Git from reaching an exception beneath it.
3. Building a useful file
Start with generated dependencies, build output, local environment files, editor metadata, operating-system files, and test artifacts. Add rules only when the project has a reason for them. Overly broad patterns can hide a legitimate source file and make a new developer wonder why Git does not show it.
# Dependencies and build output
node_modules/
dist/
.astro/
# Local configuration
.env
.env.*
!.env.example
# Logs and editor files
*.log
.vscode/
.idea/
.DS_StoreKeep an example configuration such as .env.example tracked with placeholder values. It documents required settings without distributing real secrets. Language templates are a starting point, not a substitute for reviewing the repository's actual build system.
4. Secrets and already-tracked files
The most important rule is operational: do not rely on ignore rules to protect a secret that has already been committed. If a key appears in a commit, treat it as exposed. Revoke it with the provider, replace it, and inspect logs for use. Removing the current file does not erase old commits from every clone or fork.
Use the Secret Scanner before creating a commit and add pre-commit or CI scanning for defense in depth. Review generated files too; build output can contain embedded URLs, tokens, source maps, or configuration that was safe only on the server.
5. Team maintenance
- Keep the root file focused on rules shared by every contributor.
- Use a global Git excludes file for personal editor or OS files that do not belong in the repository.
- Document exceptions in comments with the reason, not just the pattern.
- Review ignore changes like code because they change what enters version control.
- Test patterns with
git check-ignore -v path. - Make sure required fixtures, lockfiles, migrations, and deployment manifests are not accidentally ignored.
For a new project, the .gitignore Generator can combine common templates. After generation, compare the result with the repository's package manager, framework, deployment target, and secret-handling policy.
6. Common mistakes
- Ignoring the entire config directory: useful templates and documentation disappear with local secrets.
- Adding a rule after the leak: existing tracked files are unaffected.
- Ignoring lockfiles: reproducible builds become harder.
- Using a global ignore for project files: teammates cannot see why a required file is missing.
- Copying a giant template: irrelevant rules hide mistakes.
- Assuming Git ignores empty directories: Git tracks files, not empty directory entries.
Conclusion
A good .gitignore keeps generated and local-only material out of collaboration without hiding source or pretending to secure secrets. Generate a sensible baseline, review each pattern, test with Git's diagnostic command, and pair ignore rules with rotation and secret scanning.
Frequently Asked Questions
- Does .gitignore protect secrets?
- No. It prevents ordinary tracking of untracked paths but is not encryption or a history cleanup mechanism.
- What if a secret is already committed?
- Revoke and rotate it immediately, then remove it from history through a planned repository migration if needed.
- Should .env.example be committed?
- Yes, when it contains placeholders and documents required variables without real credentials.
- How do I test an ignore rule?
- Use git check-ignore -v followed by the path to see the matching rule.
- Should lockfiles be ignored?
- Usually no; lockfiles are commonly required for reproducible dependency installation.
- Can I re-include a file?
- Yes, with a later negation pattern, provided parent directories are accessible to Git.