The gitignore root template is always the current version, by rule

The root is a popularity ranking, and community/ is where everything else waits

Three directories, three different claims on your project.

The root holds templates in common use for popular languages and technologies. The stated purpose is to help people get started and to ensure you are not committing unimportant files into your repository, which is a low bar and a deliberate one: a root template is meant to be a safe starting set, not a complete one.

Global holds templates for editors, tools and operating systems. These apply to the machine rather than the project.

community holds specialized templates for other popular languages, tools and projects that do not currently belong in the mainstream set, and the guidance is to add them to your project-specific template at the moment you decide to adopt that framework or tool.

The consequence of the split is that the same tool can sit in more than one place, and picking the wrong one is how you end up with a template that is too small or too large. A new project starts from the root. A specific framework gets added later from community. Editor and OS noise goes to Global, or nowhere.

The root template is evergreen, so old major versions are parked and frozen

This is the rule with the sharpest consequence for anyone still on an old release. Some templates change greatly between versions, and contributing them follows a specific flow.

The template at the root should be the current supported version. The template at the root should not have a version in the filename, described as evergreen. Previous versions of templates should live under community. Previous versions should embed the version in the filename, for readability.

The rationale given is that this helps users get the latest version, because they use whatever is at the root, while also letting maintainers support older versions still in the wild.

Read that second clause against the first. A team on version 3 of a framework whose root template now describes version 5 cannot use the root template, because the root template is by construction the current one. They need a community copy with the version in the filename, and that copy receives no further attention once a new major ships. Nobody is maintaining your old major version. The path back is to write and maintain those rules yourself.

A template is a header comment, some patterns, and negations that put files back

There is exactly one worked example in the repository, and it is worth reading line by line because it shows the three things a template does. It would live at community/DotNet/InforCRM.gitignore.

# gitignore template for InforCRM (formerly SalesLogix)
# website: https://www.infor.com/products/customer-experience-suite/crm
#
# Recommended: VisualStudio.gitignore

# Ignore model files that are auto-generated
ModelIndex.xml
ExportedFiles.xml

# Ignore deployment files
[Mm]odel/[Dd]eployment

# Force include portal SupportFiles
!Model/Portal/*/SupportFiles/[Bb]in/
!Model/Portal/PortalTemplates/*/SupportFiles/[Bb]in

The header names the product, links its website, and points at another template in this repository as a recommendation. Composition is done by reference in a comment, not by copying rules between files.

The bracket expressions are per-character classes, so [Mm]odel matches Model or model. And the two lines starting with an exclamation mark re-include paths that the deployment rule above would otherwise have swallowed, which is the only way to carve an exception out of a broad ignore.

Global templates are machine-wide, and both installation routes have a cost

The Global directory exists for editors, tools and operating systems, and the recommendation is that you either add these to your global template or merge the rules into your project-specific templates if you want to use them permanently.

That is two options and neither is free. The global template route makes every rule apply to every repository on that machine, forever, whether or not the tool is present. An editor cache directory, a virtual environment path, a build output for a project you left two years ago: all of them become permanent exceptions in every repo you touch, including work repositories and client repositories with their own ignore rules.

Merging into a project template is the other side of the same coin. Now every project you open carries rules for tools you are not using, and the next person to read the file has to work out which half of it applies to them.

The docs link offered for this is the one on configuring ignored files for all repositories on your computer, so the mechanism is documented. Which route you pick is a choice about how much of someone else's environment your repository carries.

This list populates the GitHub.com chooser, so a bad rule becomes a default

The consequence of a wrong pattern here is not a wrong file in your repository. This collection is the data source for the .gitignore template choosers in the GitHub.com interface, used when creating new repositories and new files. A rule that is too broad ships inside the product, where a person who has never read a gitignore pattern accepts it as the starting point for a project they have not written yet.

That is why the acceptance criteria are about curating rather than coverage. A template should contain a set of rules to help Git repositories work with a specific language, framework, tool or environment, and if it is not possible to curate a small set of useful rules, the template is not a good fit. A template that is mostly a list of files installed by a particular version of some software, a PHP framework being the example given, belongs under community instead.

The stated aim is to curate the most common and helpful templates, not to cover every project that exists, and a missing tool is explicitly not a judgement on that tool.

Promotion to the root is deferred, sometimes for a long time

Contributions are accepted against a standard and then parked, and the mechanism is stated plainly rather than left implicit.

The proposed flow is four steps. Fork the project to your own account. Create a branch for the change. Make the changes in the fork. Send a pull request from that branch to the main branch. The web interface does the forking and the prompt for you if you would rather not use a terminal.

What happens to the pull request is the part to read. A contribution has to follow the contributing guidelines, and a template that is important and visible may not be accepted immediately, because the project can promote it to the root at a later date based on interest. The root is the curated, mainstream position, and entry to it is a judgement call made on timing as much as on merit.

For a maintainer of a niche tool this is the practical shape of the whole thing. Your template is accepted into community, where it is useful, and moving up to root happens if enough people ask, when they ask.

CC0 waives the credit, and a vendored template can never be credited back

The licence is CC0-1.0, and that is unusual enough to be worth stating precisely because of what it removes.

There is no attribution requirement. You can copy a template into your own project, or into the template your own scaffolding tool generates, and you do not owe a credit line, a licence header, or a link back to this repository. No other widely used git template collection is this permissive by default, and for a company generating .gitignore files across a portfolio of repositories that removes a whole category of legal review.

The other side is authorship. A CC0 dedication covers the template as published, so a file you modified and renamed is still carrying rules that came from somewhere public, and nothing in CC0 gives you a way to claim the original patterns as your own work. If your organisation needs an internal audit trail for where a rule came from, CC0 removes the obligation to record it and removes your ability to prove it later.

Record the source commit yourself if that matters, because the repository has no releases to reference.

Editorial conclusion

Take a template from the root when you are starting a project and want a sane starting set, from Global when you want editor and operating system noise out of a repository, and from community once you have adopted a specific framework. Do not expect to find a template here that covers a pinned old major version, because the root is evergreen by rule and previous versions sit under community where they stop being revised. Before you vendor any template into your own generator or build, record the commit you took it from, since the repository has no releases and nothing tells you a template changed. And note what CC0 costs you: you can drop the credit entirely, and you also cannot claim authorship of rules you did not write.

Frequently asked questions

Official sources

1. Official README
2. Project repository