.gitignore Generator

Pick the languages, frameworks, editors and operating systems you use and get them merged into a single .gitignore. Sections are labelled, repeated patterns are removed, and no line is moved. The templates come from the github/gitignore repository and ship with the page; nothing is requested from any service while it runs.

Pick your stack

Nothing selected yet.

Languages and frameworks

Editors and IDEs

Operating systems

Your own patterns

Whatever you write here is added at the very end of the file under its own heading, and it stays there every time you change your selection. Being last, it overrides the rules the templates brought.

Preview

0 Lines
0 Sections
0 Patterns
0 Duplicates removed


            

How do you create a .gitignore file?

  1. Pick your stack

    Tick the languages and frameworks you use. You can also find them by typing in the search box; what you pick collects as tags above the list.

  2. Add your editor and operating system

    Editors such as VS Code, JetBrains and Vim sit in their own group, and so do the macOS, Windows and Linux templates. They are written at the end of the file, the way you would write it by hand.

  3. Write your own rules

    Put the patterns that are specific to your project in the box below. Being last they override the rules the templates brought, and they survive a change of selection.

  4. Copy it, or download it as .gitignore

    The preview shows the line count and how many duplicates were removed. Copy the file to the clipboard, or download it as .gitignore and drop it at the root of your repository.

Where do the templates come from?

Almost every template here is taken verbatim from GitHub's own github/gitignore repository. That repository is the de facto standard: the people who best know which files a language or framework produces write them there, and changes go in only after discussion. It is published under CC0 1.0, so using it carries no attribution obligation — it is credited anyway, because knowing where the list came from is precisely what makes it trustworthy.

The templates ship with the page itself. Nothing is requested from GitHub or any other service while the page runs: when an outside service slows down or hits a rate limit this tool is unaffected, and the file it produces is the same tomorrow as it is today.

A few sections upstream has no template for — Django, Flask, React, Vue — were put together by Coderspace. Every section names its source right under its heading, so the file you generate says where each line came from.

Why does order matter in a .gitignore?

To decide whether a file is ignored, Git reads the .gitignore from top to bottom and applies the LAST line that matches it. Pasting two files one after the other is therefore not the harmless act it looks like: a pattern that comes later can silently cancel an exception written earlier.

This tool never moves a line. Sections are written in a fixed order — languages and frameworks first, then editors, operating systems last — and the lines inside a section keep the order the template they came from wrote them in. The order you tick the boxes in changes nothing; the same selection always gives the same file.

Patterns What it means
build/ Ignores every directory named build, at any depth. The trailing slash means "directories only".
/build Ignores only the build at the root of the repository; files and directories of the same name in subdirectories are untouched.
*.log Ignores every file ending in .log. A star never matches a slash, but because the pattern has no slash in it the rule applies in every directory.
!.env.example An exclamation mark is an exception: it puts back a file ignored above it. If a pattern below it ignores the file again, the exception does nothing.
logs/* Ignores what is inside the directory, not the directory itself. This is the only way to write an exception: with logs/ Git never enters the directory at all, and no exception inside it can fire.

How are repeated patterns removed?

Pick Python together with Django, or Java together with Gradle, and the same pattern appears in more than one section. Deleting those blindly is wrong: if an exception sits between two identical lines, dropping the second one makes that exception permanent and changes what the file means.

This tool drops a repeat only when nothing written in between could change its verdict: a positive pattern when no exception has been written since its last appearance, an exception when no positive pattern has. In every other case the repeat stays where it is. How many lines were removed is shown above the preview.

Comment lines left with no pattern under them are dropped too, so the file carries no explanation of something that is not there.

A .gitignore cannot save a file that is already committed

This is the most common misunderstanding: a .gitignore only works on files Git is not tracking yet. Once a file has been committed, adding a pattern for it afterwards does not stop it being tracked.

To stop tracking a file while keeping it on disk, remove it from the index with git rm --cached and commit that change. If what leaked is a password, key or token, removing the file is not enough: it stays in the history, so revoke the secret and issue a new one first.

Status What to do
The file has not been committed yet Add the pattern to .gitignore; nothing else is needed.
The file is tracked git rm --cached <file>
Removes the file from the index without deleting it from disk.
A directory is tracked git rm -r --cached <directory>
Then commit the change.
I cannot tell why a rule is not working git check-ignore -v <file>
Tells you which line of which file made the decision.
Rules that are only for your own machine Put them in .git/info/exclude or your global gitignore, not in the repository.

Key features

Merges them into one

Collects language, framework, editor and operating system templates into a single file. Every section is written with its own heading and source.

Removes duplicates safely

Never writes the same pattern twice — unless dropping the repeat would change what an exception means, in which case it stays.

Always the same order

Editor and operating system sections are written last. The same selection gives the same file, whatever order you ticked it in.

Add your own rules

The patterns you write sit at the end, survive a change of selection, and override the rules the templates brought.

Remembers your selection

Your last selection and your own patterns are kept in your browser, so coming back does not mean ticking everything again.

No outside requests

The templates ship with the page. Generation happens in your browser; nothing is requested from GitHub or any other service.

FAQ

It lists the files Git should not take into the repository: build output, dependency directories, editor settings, secret keys. The file goes at the root of the repository and applies to everyone on the team. You can also put a .gitignore in a subdirectory, where it applies only to that directory and below.

Yes — that is what the tool is for. However many templates you pick, they are collected into a single file in a fixed order: languages and frameworks first, then editors, operating systems last. A pattern that appears in more than one template is written once; but if removing the repeat would change what an exception means, the repeat is kept.

Almost all of them are taken verbatim from GitHub's github/gitignore repository, published under CC0 1.0. They ship with the page, so the tool never calls GitHub while it runs. The file you generate names the upstream revision and date at the top, and every section names its source under its heading.

No. A .gitignore only looks at files Git is not tracking yet. To drop a tracked file from the index while keeping it on disk, run git rm --cached <file> and commit the change. If what leaked is a password or a token, that is still not enough: it remains in the history, so revoke the secret first.

Usually one of two reasons. Either the file is already tracked, or it is a question of order: Git applies the LAST matching line, so a pattern written later can cancel an exception written earlier. Also, with logs/ Git never enters that directory, so an exception like !logs/x inside it never fires — write logs/* instead. git check-ignore -v <file> tells you which line decided.

Yes. Write your own patterns in the box below; they are added at the very end of the file, under their own heading. Being last, they override the rules the templates brought, and they survive a change of selection. Your selection and your patterns are kept in your browser, so they are still there when you come back.

Easily get your dream job!

Sign Up
Sign up Easily
Show your programming skills
Evaluate the offers