gitignore Documentation

A collection of useful .gitignore templates

175,012 stars Unknown 1 file Β· ~2,099 tokens #git#gitignore
RAW Doc

1. Project Overview & Quickstart (github/gitignore)

File: README.md

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
# 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.


File: Global/README.md

Globally Useful gitignores

This directory contains globally useful gitignores,
e.g. OS-specific and editor specific.

For more on global gitignores:
https://help.github.com/en/github/using-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer

And a good blog post about 'em:
http://augustl.com/blog/2009/global_gitignores

2. Official Technical Reference & Guides (github/docs)

GitHub Docs

Welcome to GitHub Docs! GitHub’s documentation is open source, meaning anyone from inside or outside the company can contribute. For full contributing guidelines, visit our contributing guide.

  • Hubbers (GitHub employees): See CONTRIBUTING.md in the docs-content repository for GitHub-specific processes.

  • Open source contributors: See CONTRIBUTING.md in the docs repository for a quick-start summary.

How we sync changes across Docs repositories

There are two GitHub Docs repositories:

  • github/docs (public): Open to external contributions

  • github/docs-internal (private): For GitHub employee contributions.

The two repositories sync frequently. Content changes in one are reflected in the other. Hubbers might prefer to post in docs when working with a customer, but docs has limitations on the types of contributions it accepts to safeguard the site and our workflows. Internal contributions should usually go to docs-internal.

Important: The docs repository accepts contributions to content files (.md files in /content and select /data sections like reusables only). Infrastructure files, workflows, and site-building code are not open for external modification.

New to contributing

Here are some resources to help you get started with open source contributions:

License

This project is dual-licensed under:

  • Creative Commons Attribution 4.0 - for documentation and content in the assets, content, and data folders (see LICENSE)
  • MIT License - for code (see LICENSE-CODE)