README.md 6.9 KB
Newer Older
1
# A collection of `.gitignore` templates
2

3 4 5
This is GitHub’s collection of [`.gitignore`][man] file templates.
We use this list to populate the `.gitignore` template choosers available
in the GitHub.com interface when creating new repositories and files.
C
a note  
Chris Wanstrath 已提交
6

7 8
For more information about how `.gitignore` files work, and how to use them,
the following resources are a great place to start:
C
Chris Wanstrath 已提交
9

10 11 12
- The [Ignoring Files chapter][chapter] of the [Pro Git][progit] book.
- The [Ignoring Files article][help] on the GitHub Help site.
- The [gitignore(5)][man] manual page.
C
Chris Wanstrath 已提交
13

14 15
[man]: http://git-scm.com/docs/gitignore
[help]: https://help.github.com/articles/ignoring-files
16
[chapter]: https://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#_ignoring
17
[progit]: http://git-scm.com/book
C
Chris Wanstrath 已提交
18

19 20
## Folder structure

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

B
Brendan Forster 已提交
23 24 25 26
- 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
27 28 29 30 31
- [`Global`](./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](https://help.github.com/articles/ignoring-files/#create-a-global-gitignore)
  or merge these rules into your project-specific templates if you want to use
  them permanently.
B
Brendan Forster 已提交
32 33
- [`community`](./community) contains specialized templates for other popular
  languages, tools and project, which don't currently belong in the mainstream
34 35
  templates. These should be added to your project-specific templates when you
  decide to adopt the framework or tool.
36

B
Brendan Forster 已提交
37 38 39 40 41 42 43 44 45
## What makes a good template?

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
B
Brendan Forster 已提交
46
some software (e.g. a PHP framework), it could live under the `community`
B
Brendan Forster 已提交
47 48 49 50 51 52 53 54 55
directory. See [versioned templates](#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](#specialized-templates) for more details.

If you believe your template is important and should be highly visible, please
add details about the impact of the technology when you open a pull request. We
may not accept it immediately, but we can promote it to the root at a later date
B
Brendan Forster 已提交
56
based on interest.
B
Brendan Forster 已提交
57 58 59 60 61 62

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.

63
## Contributing guidelines
64

F
flowonyx 已提交
65
We’d love for you to help us improve this project. To help us keep this collection
66
high quality, we request that contributions adhere to the following guidelines.
67

68 69 70
- **Provide a link to the application or project’s homepage**. Unless it’s
  extremely popular, there’s a chance the maintainers don’t know about or use
  the language, framework, editor, app, or project your change applies to.
J
James Dennes 已提交
71

72 73 74 75
- **Provide links to documentation** supporting the change you’re making.
  Current, canonical documentation mentioning the files being ignored is best.
  If documentation isn’t available to support your change, do the best you can
  to explain what the files being ignored are for.
J
James Dennes 已提交
76

77 78
- **Explain why you’re making a change**. Even if it seems self-evident, please
  take a sentence or two to tell us why your change or addition should happen.
B
Brendan Forster 已提交
79
  It’s especially helpful to articulate why this change applies to _everyone_
80
  who works with the applicable technology, rather than just you or your team.
J
James Dennes 已提交
81

F
flowonyx 已提交
82
- **Please consider the scope of your change**. If your change is specific to a
83 84 85
  certain language or framework, then make sure the change is made to the
  template for that language or framework, rather than to the template for an
  editor, tool, or operating system.
86

B
Brendan Forster 已提交
87
- **Please only modify _one template_ per pull request**. This helps keep pull
88
  requests and feedback focused on a specific project or technology.
89

90 91
In general, the more you can do to help us understand the change you’re making,
the more likely we’ll be to accept your contribution quickly.
92

B
Brendan Forster 已提交
93
## Versioned templates
94

B
Brendan Forster 已提交
95 96 97 98 99 100
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")
B
Brendan Forster 已提交
101
- previous versions of templates should live under `community/`
B
Brendan Forster 已提交
102 103 104 105 106 107 108 109 110
- 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
B
Brendan Forster 已提交
111
mainstream, please consider adding this to the `community` directory under a
B
Brendan Forster 已提交
112 113 114 115
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
M
mr 已提交
116
header of the template.
B
Brendan Forster 已提交
117

B
Brendan Forster 已提交
118
For example, this template might live at `community/DotNet/InforCRM.gitignore`:
B
Brendan Forster 已提交
119 120 121

```
# gitignore template for InforCRM (formerly SalesLogix)
B
Brendan Forster 已提交
122
# website: https://www.infor.com/product-summary/cx/infor-crm/
B
Brendan Forster 已提交
123 124 125 126 127 128 129 130 131 132 133 134 135 136
#
# 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
```
137

138
## Contributing workflow
139

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

142 143 144 145 146 147 148 149
1. [Fork this project][fork] to your account.
2. [Create a branch][branch] for the change you intend to make.
3. Make your changes to your fork.
4. [Send a pull request][pr] from your fork’s branch to our `master` 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.

150
[fork]: https://help.github.com/articles/fork-a-repo/
151
[branch]: https://help.github.com/articles/creating-and-deleting-branches-within-your-repository
152
[pr]: https://help.github.com/articles/using-pull-requests/
153

154
## License
155

156
[CC0-1.0](./LICENSE).