Skip to content

Home

Jump to bottom
Bankn8II©$A edited this page Jun 10, 2026 · 3 revisions

Welcome to the github-gitignore-files wiki!

NAME gitignore - Specifies intentionally untracked files to ignore SYNOPSIS $XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore DESCRIPTION A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details. Each line in a gitignore file specifies a pattern. When deciding whether to ignore a path, Git normally checks gitignore patterns from multiple sources, with the following order of precedence, from highest to lowest (within one level of precedence, the last matching pattern decides the outcome): Patterns read from the command line for those commands that support them. Patterns read from a .gitignore file in the same directory as the path, or in any parent directory (up to the top-level of the working tree), with patterns in the higher level files being overridden by those in lower level files down to the directory containing the file. These patterns match relative to the location of the .gitignore file. A project normally includes such .gitignore files in its repository, containing patterns for files generated as part of the project build. Patterns read from $GIT_DIR/info/exclude. Patterns read from the file specified by the configuration variable core.excludesFile. Which file to place a pattern in depends on how the pattern is meant to be used. Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file. Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file. Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead. The underlying Git plumbing tools, such as git ls-files and git read-tree, read gitignore patterns specified by command-line options, or from files specified by command-line options. Higher-level Git tools, such as git status and git add, use patterns from the sources specified above.

källan:https://git-scm.com/docs/gitignore

A collection of .gitignore templates

This is GitHub’s collection of .gitignore file templates. We use this list to populate the .gitignore template choosers available in the GitHub.com interface when creating new repositories and files.

For more information about how .gitignore files work, and how to use them, the following resources are a great place to start:

Folder structure

We support a collection of templates, organized in this way:

  • The root folder contains templates in common use, to help people get started with popular programming languages and technologies. These define a meaningful set of rules to help get started, and ensure you are not committing unimportant files into your repository.
  • Global contains templates for various editors, tools and operating systems that can be used in different situations. It is recommended that you either add these to your global template or merge these rules into your project-specific templates if you want to use them permanently.
  • community contains specialized templates for other popular languages, tools, and projects that don't currently belong in the mainstream templates. These should be added to your project-specific templates when you decide to adopt the framework or tool.

What makes a good template?

First and foremost, a template contribution must adhere to our Contributing Guidelines.

A template should contain a set of rules to help Git repositories work with a specific programming language, framework, tool or environment.

If it's not possible to curate a small set of useful rules for this situation, then the template is not a good fit for this collection.

If a template is mostly a list of files installed by a particular version of some software (e.g. a PHP framework), it could live under the community directory. See versioned templates for more details.

If you have a small set of rules, or want to support a technology that is not widely in use, and still believe this will be helpful to others, please read the section about specialized templates for more details.

Include details when opening a pull request if the template is important and visible. We may not accept it immediately, but we can promote it to the root at a later date based on interest.

Please also understand that we can’t list every tool that ever existed. Our aim is to curate a collection of the most common and helpful templates, not to make sure we cover every project possible. If we choose not to include your language, tool, or project, it’s not because it’s not awesome.

Contributing guidelines

Please see our Contributing Guidelines.

Versioned templates

Some templates can change greatly between versions, and if you wish to contribute to this repository we need to follow this 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 (i.e. "evergreen")
  • previous versions of templates should live under community/
  • previous versions of the template should embed the version in the filename, for readability

This helps ensure users get the latest version (because they'll use whatever is at the root) but helps maintainers support older versions still in the wild.

Specialized templates

If you have a template that you would like to contribute, but it isn't quite mainstream, please consider adding this to the community directory under a folder that best suits where it belongs.

The rules in your specialized template should be specific to the framework or tool, and any additional templates should be mentioned in a comment in the header of the template.

For example, this template might live at community/DotNet/InforCRM.gitignore:

# gitignore template for InforCRM (formerly SalesLogix)
# website: https://www.infor.com/product-summary/cx/infor-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

Contributing workflow

Here’s how we suggest you go about proposing a change to this project:

  1. Fork this project to your account.
  2. Create a branch for the change you intend to make.
  3. Make your changes to your fork.
  4. Send a pull request from your fork’s branch to our main branch.

Using the web-based interface to make changes is fine too, and will help you by automatically forking the project and prompting to send a pull request too.

License

CC0-1.0.

Clone this wiki locally