Skip to main content

.gitignore generator

Select the environments used by your project, add custom rules, and generate a clean .gitignore file without duplicates.

  • Clipboard
  • Export

Embed this widget

Customize the result, check the live preview, then copy the code.

Preview

Embed code type

Code to copy

Responsive and automatically resized by Bethemesh.

Presets to include

Select only the technologies actually used by your project.

One rule per line. Custom rule order and repetitions are preserved.

Generated .gitignore file

Was this tool useful?

How does this tool work?

Compose a .gitignore for your repository by combining local technology templates with your own patterns. The generator produces text to review and place in your project; it does not open the repository or change Git’s index. Use it for dependencies, build output and caches. Choose exclusions based on what your project actually generates: a pattern useful elsewhere may hide a file your team needs to track.

Selected templates are assembled in catalogue order. Exact duplicate patterns across templates are removed, but overlapping patterns such as *.log and a specific path are not simplified. Custom rules are appended in their original order. Their repetitions are retained because a repeated exclusion after a negation can change the result. Backslash escapes and escaped spaces are preserved.

Git interprets patterns relative to the .gitignore location. A leading / anchors a pattern there; a trailing / targets a directory. * and ** do not always have the same scope. ! includes a previously excluded path again, but Git cannot include a file whose parent directory is entirely ignored. An initial # starts a comment; escape it when the filename really starts with that character.

The environment template ignores .env and .env.* and then adds !.env.example so a secret-free example can be tracked. Ignore rules primarily affect untracked files. A file already in the index remains tracked even if a new pattern matches it. The generator does not remove indexed files, rewrite history or scan for secrets.

How to use this tool

  1. Select relevant templates

    Choose only environments actually used in the project. Selecting every technology may introduce unnecessarily broad exclusions.

  2. Add project patterns

    Enter one rule per line and put negations after their exclusions. Section comments can be enabled or disabled.

  3. Verify with Git

    Download .gitignore, review it and inspect a path using git check-ignore -v. Check already tracked files separately before considering index changes.

Use cases

Start a Node.js repository

Combine Node dependency rules with your framework’s build output. Keep the lockfile and configuration needed for reproducible installs.

Share an environment example

Use the .env patterns and .env.example exception, then check that the example contains only dummy values.

Merge existing exclusions

Append project exceptions as custom rules and review their order. Compare the generated text with the current file before replacing it.

Examples

Keep the example file

With comments disabled, the environment template produces three lines. The exception follows the exclusions so .env.example can remain visible.

Input

environment; includeComments=false

Result

.env
.env.*
!.env.example

Preserve meaningful order

These custom rules stay in this order. The final exclusion can cancel the previous inclusion; deleting the repeated rule would change its meaning.

Input

custom: *.log
!important.log
*.log

Result

*.log
!important.log
*.log

Tips and best practices

  • Removing a secret from the latest tree does not remove it from history. Revoke exposed credentials and handle history separately.
  • For personal editor exclusions, consider .git/info/exclude or a global ignore file rather than imposing your preferences on the team.
  • Keep source files and required build configuration; ignoring dist should not hide what is needed to rebuild it.

Sources and references

Frequently asked questions

Where should I put the generated file?

Usually at the repository root. Git also supports nested .gitignore files with patterns relative to their directories. Adjust paths if you move the file.

Why does an ignored file still appear in a commit?

It may already be tracked. Patterns do not remove existing files from the index; inspect git ls-files and staged changes before acting.

Are all duplicate rules removed?

Exact repetitions across templates are removed. Custom rules keep repetitions and ordering to preserve the effect of ! exceptions.

Does this guarantee that no secrets are tracked?

No. It assembles patterns without inspecting files or history. Preventive exclusions complement a repository review rather than replacing one.

Related tools

Tools similar or complementary to this one.

Similar tools

Compare two texts line by line and quickly spot additions, deletions and changes.

DevelopmentFeaturedUse this tool

Convert Unix permissions between octal and symbolic notation and generate a chmod command.

DevelopmentUse this tool

Generate one or more random UUID v4 identifiers instantly and copy them when needed.

DevelopmentFeaturedUse this tool