Smart Deals - promotions, discount codes and sales

Gitignore Generator

Pick your stack and copy a ready ignore list into the root of your repository.

Secure (SSL)
Client-Side Processing
100% Free
Instructions
  • 1
    Enter data
    Enter content, paste text or load a file from disk.
  • 2
    Click the button
    The tool will immediately process your data in the browser.
  • 3
    Get the result
    Copy the finished text or save the file to your device.
function runTool() {
  return "Result ready in 0.1s";
}
Pick the templates to generate a .gitignore file.

Rate this tool:

5.0 / 5 · 1 rating

Related tools

Other tools you may find useful

Gitignore generator - ready-made templates for Node, PHP, Python and Java

The gitignore generator assembles a list of ignored paths from ready-made blocks: dependencies, build output, editor folders, operating system files, secrets and logs. Select the technologies you use, copy the result into the root of your repository, and keep nothing but source code in Git from the very first commit.

What a .gitignore file does

.gitignore is a list of path patterns that Git should not offer for staging. It deletes nothing from your disk and nothing from history, because it only affects untracked files. That is what keeps git status focused on real code changes instead of tens of thousands of files inside node_modules/. The file itself is versioned with the project, so the whole team works with the same rules.

What is worth ignoring in a typical repository

CategorySample patternsWhy
Dependenciesnode_modules/, /vendor/, .venv/Reproducible from the lock file, hundreds of megabytes in size
Build outputdist/, build/, target/, *.classGenerated from source and conflicts on every merge
Secrets.env, *.pem, *.keyA credential leak cannot be undone
Editors and OS.idea/, .vscode/, .DS_Store, Thumbs.dbLocal settings that differ for every developer
Logs and caches*.log, .cache/, .pytest_cache/They grow without limit and add nothing to history

The generator deliberately does not ignore dependency lock files. composer.lock, package-lock.json and yarn.lock belong in the repository, because they are the only guarantee that a deployment installs exactly the library versions you tested against.

How to use the generator

  1. Select the templates that match your project stack. You can combine several, for example Laravel and Node.js for an application with a frontend built by Vite.
  2. Click Generate .gitignore. Patterns that repeat across templates appear in the output only once.
  3. Copy the contents and save them as .gitignore in the root of your repository.
  4. Verify the result with git status — it should now list only the files you actually want to version.

When you bootstrap a new project, the tsconfig.json configuration generator is handy for the TypeScript part, and at deployment time so is the .htaccess file generator or the Kubernetes Deployment manifest generator.

The pattern syntax Git actually uses

A pattern without a slash matches at every level of the tree: *.log ignores logs in the root directory and in every subdirectory. A leading slash anchors the pattern to the directory that holds the .gitignore, so /build covers the root only, while build/ covers every directory with that name. A trailing slash narrows the rule to directories. A double asterisk crosses levels, as in docs/**/*.pdf. An exclamation mark negates a rule, with one catch: if you excluded a whole directory, you cannot pull a single file back out of it until you unblock the directory itself.

You do not have to guess which rule fired. Running git check-ignore -v path/to/file prints the file and the line number responsible for ignoring it.

Secrets - the one mistake .gitignore will not undo

Adding .env to .gitignore after the fact does not remove it from history. If a file with a password landed in a commit that reached a remote repository, treat the credentials as disclosed: revoke them and issue new ones before you start rewriting history.

Rewriting history with git filter-repo or BFG changes commit identifiers, so it needs agreement across the team and a force push. Rotating the key is faster, cheaper and necessary either way.

The file is already tracked - how to detach it

git rm --cached .env
git rm -r --cached node_modules
git commit -m "Stop tracking ignored files"

The --cached switch removes the file from the Git index but leaves it on disk. Without that step a new entry in .gitignore changes nothing, because the rules never apply to files that are already tracked. Comparing the repository before and after helps, and so does the code difference checker.

Frequently asked questions

Does .gitignore work in subdirectories?

Yes. Patterns without a leading slash match at every level of the tree. On top of that, each subdirectory can carry its own .gitignore, whose rules apply only inside that subtree and take precedence over rules from directories above. This is convenient in a monorepo where individual packages produce different build artifacts.

How do I ignore every file except one?

Exclude the pattern first, then add an exception with an exclamation mark: *.log followed by !important.log on the next line. Order matters, because the last matching rule wins. The exception will not work if you excluded the parent directory, because Git never looks inside it.

Where do I put rules I do not want to commit?

In .git/info/exclude, which behaves like .gitignore but is not versioned. Rules that apply to your whole machine, such as editor folders and operating system files, belong in a global file instead: git config --global core.excludesFile ~/.gitignore_global. That keeps the project repository free of personal settings.

Should composer.lock and package-lock.json be committed?

In applications, yes. Lock files record the exact dependency versions, and they are what lets a deployment reproduce the environment you tested. They are ignored only in libraries that need to work across a wide version range. That is why the PHP template in this generator excludes /vendor/ but keeps composer.lock in the repository.

Does .gitignore protect against leaking secrets?

Only as prevention, and only for files that are still untracked. It does not stop git add -f, it has no effect on files already added, and it removes nothing from history. Keep secrets outside the repository, in environment variables or a secrets manager, and version only .env.example with empty values.

Install Webp.pl Have the tools in your own pocket!