.gitignore: Keeping Secrets and Junk Out of Your Repo

Why you need a .gitignore

Not every file in your project belongs in the repository. Dependencies like node_modules, build output like dist/, environment secrets like .env, and OS junk like .DS_Store should never be committed. They bloat the repository, slow down clones, leak sensitive information, and create noisy diffs that obscure real changes.

Without a .gitignore, your staging panel looks like this — cluttered with files that should not be there:

With a properly configured .gitignore, the noise disappears and you only see the files that matter:

A .gitignore is one of the first files you should create in any project — ideally before your first commit. It is much easier to prevent a file from being tracked than to remove it after it has been committed.

How .gitignore works

A .gitignore file is a plain text file at the root of your repository. Each line contains a pattern that tells Git which files or directories to ignore. Ignored files will not show up in git status, cannot be staged with git add, and will never be committed.

Here is a minimal but effective .gitignore that works for most JavaScript/TypeScript projects:

# Dependencies
node_modules/

# Build output
dist/
build/

# Environment variables
.env
.env.local
.env.production

# OS files
.DS_Store
Thumbs.db

# Editor files
.vscode/settings.json
.idea/

Important rules

• .gitignore only affects untracked files. If a file is already tracked by Git (it was committed at some point), adding it to .gitignore will not stop tracking it. You need an extra step — covered later in this article.
• Patterns are matched relative to the location of the .gitignore file.
• You can have multiple .gitignore files in subdirectories. Each one applies to its own directory and below.
• Lines starting with # are comments. Blank lines are ignored.

Debugging with git check-ignore

Not sure if a file is being ignored? Use git check-ignore to test it:

Pattern syntax

The .gitignore pattern language is simple but powerful. Here is a complete reference with examples:

# Ignore a specific file
secrets.json

# Ignore all files with an extension
*.log
*.tmp
*.bak

# Ignore an entire directory (trailing slash)
node_modules/
dist/
.cache/

# Wildcard — matches any single directory level
docs/*/draft.md          # docs/api/draft.md ✓  docs/api/v2/draft.md ✗

# Double wildcard — matches any number of directories
**/test/**               # src/test/unit.ts ✓  test/e2e.ts ✓

# Negate a pattern — re-include something previously ignored
*.log
!important.log           # All .log files ignored EXCEPT important.log

# Ignore files only in the root directory
/TODO.md                 # Ignores ./TODO.md but not docs/TODO.md

# Comments start with #
# Blank lines are ignored

Let's walk through each pattern type:

.env
secrets.json
.DS_Store

*.log           # All .log files: app.log, error.log, etc.
*.min.js        # All minified JS files
temp_*          # Files starting with temp_

node_modules/   # The entire node_modules tree
dist/           # Build output
.cache/         # Cache directory
coverage/       # Test coverage reports

**/node_modules/    # node_modules at ANY depth
**/test/**          # Anything inside any test/ directory
logs/**/*.log       # .log files inside logs/ at any depth

# Ignore all .env files...
.env*

# ...but keep the example file
!.env.example

Order matters when using negation. Git processes .gitignore top to bottom. A negation pattern (!) must come after the rule it overrides. If the ignore rule comes after the negation, the file will still be ignored.

Common templates by language

Every language and framework has its own set of files that should be ignored. Here are ready-to-use templates for the most popular stacks:

Node.js / TypeScript / React

# Dependencies
node_modules/

# Build output
dist/
build/
.next/
out/

# Environment variables
.env
.env.local
.env.*.local

# Debug logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# OS files
.DS_Store
Thumbs.db

# Testing
coverage/

# IDE
.vscode/
.idea/
*.swp
*.swo

Python

# Virtual environments
venv/
.venv/
env/

# Byte-compiled files
__pycache__/
*.py[cod]
*$py.class

# Distribution
dist/
build/
*.egg-info/
*.egg

# Environment variables
.env

# IDE
.vscode/
.idea/
*.swp

# Testing
.pytest_cache/
htmlcov/
.coverage

# Jupyter
.ipynb_checkpoints/

Rust

# Build output
target/

# Cargo lock for libraries (keep it for binaries)
# Cargo.lock

# IDE
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

# Environment
.env

For other languages and frameworks, the gitignore.io service generates templates for hundreds of technologies. You can also browse the official GitHub gitignore repository for community-maintained templates.

Removing already tracked files

This is one of the most common mistakes: you commit a file, later add it to .gitignore, but it keeps showing up in diffs. That is because .gitignore only prevents new tracking — it does not untrack files that Git already knows about.

To fix this, you need to remove the file from Git's index while keeping it on disk:

Warning: If the file contains secrets (like an .env file), untracking it is not enough. The file still exists in your Git history. Anyone who clones the repository can see it by browsing old commits. If secrets were committed, you should rotate them (generate new keys/passwords) immediately.

Bulk untrack

If you added .gitignore late and many tracked files need to be removed, you can untrack everything and re-add in one go. Git will only re-add files that are not ignored:

.gitignore in Komitly

Komitly provides a dedicated Gitignore Editor accessible from the Activity Rail. It replaces manually editing a text file with a visual interface that makes managing ignore rules fast and intuitive.

The Gitignore Editor

The editor shows your current .gitignore with syntax highlighting, so patterns, comments, and negation rules are visually distinct. You can edit the file directly, and changes are saved to disk in real time.

Language templates

Komitly includes built-in templates for common languages and frameworks. Select a template from the dropdown and the relevant patterns are added to your .gitignoreautomatically — no need to look up what to ignore for each technology.

Add from context menu

The fastest way to ignore a file is directly from the staging panel. Right-click any file and select Add to .gitignore. Komitly appends the correct pattern to your .gitignore and the file immediately disappears from the unstaged list. No manual editing required.

See a file in the staging panel that should not be there? Right-click it and select "Add to .gitignore." Komitly writes the pattern for you, and the file vanishes from the panel instantly.

Summary

A well-configured .gitignore keeps your repository clean, your diffs readable, and your secrets safe. Here is a quick recap:

• Create a .gitignore before your first commit. Include dependencies, build output, environment variables, and OS files.
• Use * for wildcards, / for directories, ** for recursive matching, and ! to negate a pattern.
• .gitignore only affects untracked files. Use git rm --cached to untrack files that were committed before the ignore rule existed.
• Use git check-ignore -v to debug whether a file is being ignored and which pattern matched.
• Start with a template for your language (Node.js, Python, Rust, etc.) and customize from there.
• In Komitly, use the Gitignore Editor for syntax-highlighted editing, built-in language templates, and the right-click "Add to .gitignore" shortcut from the staging panel.

With .gitignore in place, your repository stays lean and focused on the code that matters. Next, learn how to write better commit messages that your future self will thank you for.