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:
Komitly - Without .gitignore
Staged (2)
Msrc/App.tsx
Asrc/utils/api.ts
Changes (6)
A.env
A.env.local
?node_modules/.package-lock.json
?dist/bundle.js
?dist/bundle.js.map
?.DS_Store
With a properly configured .gitignore, the noise disappears and you only see the files that matter:
Komitly - With .gitignore
Staged (2)
Msrc/App.tsx
Asrc/utils/api.ts
Changes (0)
Working tree clean
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:
.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:
Terminal
$ git check-ignore -v .env
.gitignore:8:.env .env
$ git check-ignore -v src/App.tsx
# No output — file is NOT ignored
$ git check-ignore -v .env
Hover over each part to see what it does
Pattern syntax
The .gitignore pattern language is simple but powerful. Here is a complete reference with examples:
Pattern syntax reference
# 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:
.gitignore
.env
secrets.json
.DS_Store
.gitignore
*.log # All .log files: app.log, error.log, etc.
*.min.js # All minified JS files
temp_* # Files starting with temp_
.gitignore
node_modules/ # The entire node_modules tree
dist/ # Build output
.cache/ # Cache directory
coverage/ # Test coverage reports
.gitignore
**/node_modules/ # node_modules at ANY depth
**/test/** # Anything inside any test/ directory
logs/**/*.log # .log files inside logs/ at any depth
.gitignore
# 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:
# 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:
Terminal
# Oops — .env was committed before adding it to .gitignore
# Step 1: Add the pattern to .gitignore
$ echo '.env' >> .gitignore
# Step 2: Remove the file from Git's tracking (keeps the file on disk)
$ git rm --cached .env
rm '.env'
# Step 3: Commit the change
$ git add .gitignore
$ git commit -m "Stop tracking .env file"
[main a1b2c3d] Stop tracking .env file
2 files changed, 1 insertion(+), 1 deletion(-)
$ git rm --cached .env
Hover over each part to see what it does
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:
Terminal
# Remove ALL ignored files from tracking at once
$ git rm -r --cached .
rm 'node_modules/.package-lock.json'
rm 'dist/bundle.js'
rm 'dist/bundle.js.map'
rm '.DS_Store'
$ git add .
$ git commit -m "Untrack files now in .gitignore"
[main b2c3d4e] Untrack files now in .gitignore
.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.