You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

README.md 6.9KB

13 jaren geleden
13 jaren geleden
13 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
4 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
4 jaren geleden
5 jaren geleden
5 jaren geleden
5 jaren geleden
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155
  1. # A collection of `.gitignore` templates
  2. This is GitHub’s collection of [`.gitignore`][man] file templates.
  3. We use this list to populate the `.gitignore` template choosers available
  4. in the GitHub.com interface when creating new repositories and files.
  5. For more information about how `.gitignore` files work, and how to use them,
  6. the following resources are a great place to start:
  7. - The [Ignoring Files chapter][chapter] of the [Pro Git][progit] book.
  8. - The [Ignoring Files article][help] on the GitHub Help site.
  9. - The [gitignore(5)][man] manual page.
  10. [man]: http://git-scm.com/docs/gitignore
  11. [help]: https://help.github.com/articles/ignoring-files
  12. [chapter]: https://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#_ignoring
  13. [progit]: http://git-scm.com/book
  14. ## Folder structure
  15. We support a collection of templates, organized in this way:
  16. - The root folder contains templates in common use, to help people get started
  17. with popular programming languages and technologies. These define a meaningful
  18. set of rules to help get started, and ensure you are not committing
  19. unimportant files into your repository.
  20. - [`Global`](./Global) contains templates for various editors, tools and
  21. operating systems that can be used in different situations. It is recommended
  22. that you either [add these to your global template](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer)
  23. or merge these rules into your project-specific templates if you want to use
  24. them permanently.
  25. - [`community`](./community) contains specialized templates for other popular
  26. languages, tools and project, which don't currently belong in the mainstream
  27. templates. These should be added to your project-specific templates when you
  28. decide to adopt the framework or tool.
  29. ## What makes a good template?
  30. A template should contain a set of rules to help Git repositories work with a
  31. specific programming language, framework, tool or environment.
  32. If it's not possible to curate a small set of useful rules for this situation,
  33. then the template is not a good fit for this collection.
  34. If a template is mostly a list of files installed by a particular version of
  35. some software (e.g. a PHP framework), it could live under the `community`
  36. directory. See [versioned templates](#versioned-templates) for more details.
  37. If you have a small set of rules, or want to support a technology that is not
  38. widely in use, and still believe this will be helpful to others, please read the
  39. section about [specialized templates](#specialized-templates) for more details.
  40. Include details when opening pull request if the template is important and visible. We
  41. may not accept it immediately, but we can promote it to the root at a later date
  42. based on interest.
  43. Please also understand that we can’t list every tool that ever existed.
  44. Our aim is to curate a collection of the _most common and helpful_ templates,
  45. not to make sure we cover every project possible. If we choose not to
  46. include your language, tool, or project, it’s not because it’s not awesome.
  47. ## Contributing guidelines
  48. We’d love for you to help us improve this project. To help us keep this collection
  49. high quality, we request that contributions adhere to the following guidelines.
  50. - **Provide a link to the application or project’s homepage**. Unless it’s
  51. extremely popular, there’s a chance the maintainers don’t know about or use
  52. the language, framework, editor, app, or project your change applies to.
  53. - **Provide links to documentation** supporting the change you’re making.
  54. Current, canonical documentation mentioning the files being ignored is best.
  55. If documentation isn’t available to support your change, do the best you can
  56. to explain what the files being ignored are for.
  57. - **Explain why you’re making a change**. Even if it seems self-evident, please
  58. take a sentence or two to tell us why your change or addition should happen.
  59. It’s especially helpful to articulate why this change applies to _everyone_
  60. who works with the applicable technology, rather than just you or your team.
  61. - **Please consider the scope of your change**. If your change is specific to a
  62. certain language or framework, then make sure the change is made to the
  63. template for that language or framework, rather than to the template for an
  64. editor, tool, or operating system.
  65. - **Please only modify _one template_ per pull request**. This helps keep pull
  66. requests and feedback focused on a specific project or technology.
  67. In general, the more you can do to help us understand the change you’re making,
  68. the more likely we’ll be to accept your contribution quickly.
  69. ## Versioned templates
  70. Some templates can change greatly between versions, and if you wish to contribute
  71. to this repository we need to follow this specific flow:
  72. - the template at the root should be the current supported version
  73. - the template at the root should not have a version in the filename (i.e.
  74. "evergreen")
  75. - previous versions of templates should live under `community/`
  76. - previous versions of the template should embed the version in the filename,
  77. for readability
  78. This helps ensure users get the latest version (because they'll use whatever is
  79. at the root) but helps maintainers support older versions still in the wild.
  80. ## Specialized templates
  81. If you have a template that you would like to contribute, but it isn't quite
  82. mainstream, please consider adding this to the `community` directory under a
  83. folder that best suits where it belongs.
  84. The rules in your specialized template should be specific to the framework or
  85. tool, and any additional templates should be mentioned in a comment in the
  86. header of the template.
  87. For example, this template might live at `community/DotNet/InforCRM.gitignore`:
  88. ```
  89. # gitignore template for InforCRM (formerly SalesLogix)
  90. # website: https://www.infor.com/product-summary/cx/infor-crm/
  91. #
  92. # Recommended: VisualStudio.gitignore
  93. # Ignore model files that are auto-generated
  94. ModelIndex.xml
  95. ExportedFiles.xml
  96. # Ignore deployment files
  97. [Mm]odel/[Dd]eployment
  98. # Force include portal SupportFiles
  99. !Model/Portal/*/SupportFiles/[Bb]in/
  100. !Model/Portal/PortalTemplates/*/SupportFiles/[Bb]in
  101. ```
  102. ## Contributing workflow
  103. Here’s how we suggest you go about proposing a change to this project:
  104. 1. [Fork this project][fork] to your account.
  105. 2. [Create a branch][branch] for the change you intend to make.
  106. 3. Make your changes to your fork.
  107. 4. [Send a pull request][pr] from your fork’s branch to our `main` branch.
  108. Using the web-based interface to make changes is fine too, and will help you
  109. by automatically forking the project and prompting to send a pull request too.
  110. [fork]: https://help.github.com/articles/fork-a-repo/
  111. [branch]: https://help.github.com/articles/creating-and-deleting-branches-within-your-repository
  112. [pr]: https://help.github.com/articles/using-pull-requests/
  113. ## License
  114. [CC0-1.0](./LICENSE).