.gitignore Generator

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.

.gitignore only affects UNTRACKED files. Once a file has been committed, Git keeps tracking it regardless of .gitignore — the rule simply doesn't apply retroactively. To stop tracking a file that's already in the repo, remove it from Git's index while keeping it on disk: git rm --cached <file> (add -r for a directory), then commit the removal. After that, the .gitignore rule takes effect and Git ignores future changes. This is the classic 'I added node_modules/ to .gitignore but it's still showing up' situation — the directory was committed before the rule existed. Run git rm -r --cached node_modules and commit, and it's gone from tracking (but still on your disk).

Act fast, because the secret is compromised the moment it's pushed — even if you delete it in a later commit, it remains in the Git HISTORY where anyone with repo access can recover it. Steps: (1) ROTATE the secret immediately — generate new API keys, tokens, passwords; assume the old ones are burned. This is the most important step and is non-negotiable for pushed secrets. (2) Remove it from history with git filter-repo (the modern recommended tool) or the BFG Repo-Cleaner, then force-push the cleaned history and have collaborators re-clone. (3) Add the file to .gitignore so it can't happen again, and consider a pre-commit hook (git-secrets, gitleaks) to catch secrets before they're committed. Just deleting the file in a new commit is NOT enough — rotation plus history scrubbing is required.