README.md 4.4 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 23 24 25 26 27 28 29 30 31
We support a collection of templates, organized in this way:

- [`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.
- [`ecosystem`](./ecosystem) contains specialized templates coalescing around
  popular programming languages, but don't make sense to live in the mainstream
  templates. These should be added to your project-specific templates when you
  decide to adopt the framework or tool.
32 33

## Contributing guidelines
34

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

38 39 40
- **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 已提交
41

42 43 44 45
- **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 已提交
46

47 48
- **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 已提交
49
  It’s especially helpful to articulate why this change applies to _everyone_
50
  who works with the applicable technology, rather than just you or your team.
J
James Dennes 已提交
51

F
flowonyx 已提交
52
- **Please consider the scope of your change**. If your change is specific to a
53 54 55
  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.
56

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

60 61
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.
62

63 64 65 66 67
If a template is mostly a list of files installed by a particular version of
some software (e.g. a PHP framework) then it's brittle and probably no more
helpful than a simple `ls`. If it's not possible to curate a small set of
useful rules, then the template might not be a good fit for this collection.

68
Please also understand that we can’t list every tool that ever existed.
B
Brendan Forster 已提交
69
Our aim is to curate a collection of the _most common and helpful_ templates,
70 71 72
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.

73
## Contributing workflow
74

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

77 78 79 80 81 82 83 84
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.

85
[fork]: https://help.github.com/articles/fork-a-repo/
86
[branch]: https://help.github.com/articles/creating-and-deleting-branches-within-your-repository
87
[pr]: https://help.github.com/articles/using-pull-requests/
88

89
## License
90

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