Cron Expression Parser
Read a cron expression in plain English and see when it next runs.
Build a .gitignore from templates for your stack, editor and OS.
One pattern per line. Lines starting with # are kept as comments.
The Gitignore Generator merges templates for your language, framework, editor and operating system into one labelled file, dropping every pattern the moment it has already been written — which is what pasting three gitignore files together never does.
A .gitignore is one of those files that everyone copies from the last project and nobody quite reads. Pick the templates that match what you are building and this merges them into one file, with each section labelled so it stays maintainable.
The merge matters more than the templates do. Paste three gitignore files together by hand and you get `node_modules/` three times, a wall of comments for sections that contributed nothing, and no way to tell later which rule came from where. This drops a pattern the moment it has already been written, removes any section left with only its comments, and keeps the headings — so the result reads like a file somebody wrote rather than one somebody assembled.
Node, React and Next all list node_modules/. It appears once, in the first section that claimed it, rather than three times.
Each template becomes a named block, so in a year you can still tell which rule came from where and delete the ones that no longer apply.
A template whose every pattern was already covered contributes nothing, so its heading and comments are dropped instead of left as noise.
Go’s vendor/ and CocoaPods’ Pods/ are included but commented out, because teams genuinely disagree and the file should not decide for you.
Twelve languages, nine frameworks, three operating systems, five editors and the build tools that litter a working tree.
Choose a language, a framework, your editor and your operating system.
Type extra patterns for this project in the custom box.
Each template becomes a labelled section with its own patterns.
Save it as .gitignore in the root of your repository.
Because a repository belongs to everyone working on it, and your .idea/ or .vscode/ folder is yours. The usual alternative — a global gitignore on your own machine — works, but it does nothing for the next person who clones the project.
No, and this catches people out constantly. Git only ignores files it is not already tracking. Run `git rm --cached path/to/file` first, then commit; the ignore rule takes over from there.
For an application, yes — package-lock.json, composer.lock and Cargo.lock are how you get the same dependency tree in production as on your laptop. For a published library, leave Cargo.lock out so consumers resolve their own versions.
Where the right answer depends on your project. `vendor/` in Go and `Pods/` in CocoaPods are both committed by some teams and ignored by others, so those lines are present but disabled rather than decided for you.
What people who use the Gitignore Generator think of it. Reviews come from visitors and are posted as written.
No ratings yet
Yours would be the first.
0 reviews
Newest first
No reviews yet
Be the first to rate the Gitignore Generator. It takes half a minute and no account.
Write the first reviewRead a cron expression in plain English and see when it next runs.
Convert a name between camelCase, snake_case, kebab-case and the rest.
Stack CSS filters on a real image and copy the declaration.
Inspect any character: code point, block, category, UTF-8 bytes and escapes.
See your own user agent string and what a server can tell from it.
Convert internationalised domain names to punycode and back.
Generate believable company names, domains and details for mockups.
Generate time-ordered UUID v7 identifiers that index cleanly.