Generate a custom .gitignore file by selecting your tech stack. Covers Node.js, Python, Java, Go, Rust, Docker, Terraform, VS Code, JetBrains, macOS, and more.
Language / Runtime
Framework
Tools & DevOps
Operating System
Editor / IDE
Custom Rules
.gitignore Generator creates a custom .gitignore file tailored to your project's tech stack by combining curated templates for programming languages, frameworks, operating systems, and editors. Select the technologies you use — for example, Node.js + Docker + VS Code + macOS — and get a comprehensive, well-commented .gitignore that covers all the files that should never enter your version control system.
Use .gitignore Generator when starting a new repository to set up proper ignore rules before making your first commit, when adding a new language or tool to an existing project, when onboarding a project that lacks a comprehensive .gitignore, or when you need to quickly look up what files a specific framework or language generates that should not be committed.
Developers use .gitignore Generator to prevent committing node_modules and build artifacts in JavaScript projects, exclude Python virtual environments and __pycache__ from Python repositories, keep macOS .DS_Store files and JetBrains .idea/ folders out of shared repositories, prevent Terraform state files containing sensitive infrastructure data from being committed, and ensure Docker override files and environment variable files stay local.
Essential terms and definitions related to .gitignore Generator.
A wildcard pattern syntax used in .gitignore to match files and directories. The asterisk (*) matches any sequence of characters within a path segment (but not /). The double asterisk (**) matches any number of path segments. The question mark (?) matches exactly one character. Square brackets ([abc]) match any one of the listed characters. Example: *.log matches all files ending in .log at any depth.
A .gitignore pattern starting with ! that re-includes a file previously excluded by another rule. For example: /config/* ignores everything in /config, but !config/default.json re-includes that specific file. Negation is powerful for "ignore all except" patterns. Note: you cannot re-include a file if its parent directory is ignored — you must un-ignore the parent directory first.
A tracked file is one that Git knows about — it was added to the repository with git add and has at least one commit. An untracked file is one that exists in the working directory but has never been staged or committed. .gitignore only prevents untracked files from appearing in git status as "untracked" and prevents git add . from staging them. It has no effect on already-tracked files.
A Git command that removes a file from the index (staging area / tracking) without deleting it from the filesystem. This is the correct command to stop tracking a file that was previously committed but should now be ignored. After running git rm --cached <file>, add the file to .gitignore and commit both changes to permanently stop tracking it.
A .gitignore file tells Git which files and directories to ignore when tracking changes and making commits. Without it, you would accidentally commit files that should never be in version control: dependency directories (node_modules, vendor), compiled binaries, environment variable files (.env), editor-specific settings, and operating system metadata (.DS_Store on macOS). These files make repositories bloated, can expose secrets, and create unnecessary merge conflicts across different developer environments.
The primary .gitignore file belongs in the root of your repository. Git also supports nested .gitignore files in subdirectories for rules that apply only to that directory, and a global ~/.gitignore_global file for rules that apply to all repositories on your machine. The root .gitignore is the most important — it covers your project's generated files, dependencies, and configuration. A global .gitignore is useful for editor files (.DS_Store, .vscode, .idea) that you don't want to add to every project.
Yes — lock files should be committed for application projects. Lock files ensure all developers and CI/CD pipelines install exactly the same dependency versions, preventing "works on my machine" bugs. The Node.js template in this generator excludes lock files by default (as some teams prefer not to commit them), but you should remove those lines if you are building an application. For libraries published to npm, the convention is to not commit lock files so consumers use fresh dependency resolution.
.gitignore lists files that Git should not track. .gitkeep is a convention (not a Git feature) for an empty placeholder file placed inside an empty directory to force Git to track the directory — since Git does not track empty directories. A common pattern is to create a directory like /tmp/, add it to .gitignore to ignore its contents, but add a .gitkeep file inside it so the directory structure is committed.
If a file was already committed before you added it to .gitignore, Git continues to track it. .gitignore only prevents untracked files from being added — it does not retroactively untrack files. To stop tracking a file that was already committed, run: git rm --cached .env. This removes it from the index (staging area) without deleting the file from your filesystem. After that, commit the removal, and Git will no longer track it.
Use both for different purposes. The global ~/.gitignore_global should contain editor and OS-specific rules that are personal to your development environment (like .DS_Store, .vscode, .idea, Thumbs.db) — these should not be in project repositories because different team members use different editors and operating systems. The per-project .gitignore should contain rules specific to that project's tech stack (node_modules, build/, .env) that apply regardless of who is working on the project.
Common errors developers encounter and how to resolve them.
Files are still tracked after adding them to .gitignore Git only ignores files that are not already tracked. Run git rm --cached <file> (for a single file) or git rm -r --cached . (for all tracked files matching new .gitignore rules) to remove the files from the index. Then commit the changes. This tells Git to stop tracking them going forward without deleting the files locally. For sensitive files like .env, also remove them from the git history using tools like git-filter-repo.
.gitignore rules not working for files in subdirectories A pattern like build/ matches a directory named "build" at any level. A pattern starting with / (like /build/) only matches at the root of the repository. A pattern without any slash matches the file or directory anywhere in the repo tree. Check if your pattern is too specific (starts with /) or needs a wildcard. Run git check-ignore -v <file> to see exactly which .gitignore rule (if any) applies to a specific file.
Accidentally committed .env or secrets to the repository If secrets were committed, you must treat them as compromised and rotate all affected keys, tokens, and passwords immediately. Then remove the file from git history using git-filter-repo (the recommended tool) or the BFG Repo Cleaner. Force-push the cleaned history and notify all collaborators to re-clone. For GitHub repositories, contact GitHub support to purge their caches. Prevention: add .env to .gitignore before your first commit and use git-secrets or pre-commit hooks to prevent future accidents.