gitignore

Une collection de modèles .gitignore

Il s'agit de la collection de modèles de fichiers .gitignore de GitHub. Nous utilisons cette liste pour remplir les .gitignore Template Choosers disponibles dans l'interface github.com lors de la création de nouveaux référentiels et fichiers.

Pour plus d'informations sur le fonctionnement des fichiers .gitignore et de la façon de les utiliser, les ressources suivantes sont un excellent point de départ:

• Le chapitre d'ignorance des fichiers du livre Pro git.
• L'article d'ignorance des fichiers sur le site d'aide GitHub.
• La page manuelle Gitignore (5).

Structure de dossier

Nous soutenons une collection de modèles, organisés de cette manière:

• Le dossier racine contient des modèles à usage courant, pour aider les gens à démarrer avec des langages et des technologies de programmation populaires. Ceux-ci définissent un ensemble significatif de règles pour vous aider à démarrer et vous assurer que vous n'engagez pas de fichiers sans importance dans votre référentiel.
• Global contient des modèles pour divers éditeurs, outils et systèmes d'exploitation qui peuvent être utilisés dans différentes situations. Il est recommandé de les ajouter à votre modèle global ou de fusionner ces règles dans vos modèles spécifiques au projet si vous souhaitez les utiliser en permanence.
• community contient des modèles spécialisés pour d'autres langues, outils et projet populaires, qui n'appartiennent pas actuellement aux modèles grand public. Ceux-ci doivent être ajoutés à vos modèles spécifiques au projet lorsque vous décidez d'adopter le cadre ou l'outil.

Qu'est-ce qui fait un bon modèle?

Un modèle doit contenir un ensemble de règles pour aider les référentiels GIT à travailler avec un langage de programmation spécifique, un cadre, un outil ou un environnement.

S'il n'est pas possible de gérer un petit ensemble de règles utiles pour cette situation, le modèle n'est pas un bon ajustement pour cette collection.

Si un modèle est principalement une liste de fichiers installés par une version particulière de certains logiciels (par exemple un framework PHP), il pourrait vivre sous le répertoire community . Voir les modèles versionnés pour plus de détails.

Si vous avez un petit ensemble de règles ou si vous souhaitez soutenir une technologie qui n'est pas largement utilisée, et croyez toujours que cela sera utile aux autres, veuillez lire la section sur les modèles spécialisés pour plus de détails.

Incluez les détails lors de l'ouverture de la demande de traction si le modèle est important et visible. Nous ne pouvons pas l'accepter immédiatement, mais nous pouvons le promouvoir à la racine à une date ultérieure en fonction de l'intérêt.

Veuillez également comprendre que nous ne pouvons pas répertorier tous les outils qui ont jamais existé. Notre objectif est de gérer une collection des modèles les plus courants et les plus utiles , pour ne pas s'assurer que nous couvrons chaque projet possible. Si nous choisissons de ne pas inclure votre langue, votre outil ou votre projet, ce n'est pas parce que ce n'est pas génial.

Lignes directrices contributives

Nous aimerions nous aider à améliorer ce projet. Pour nous aider à maintenir cette collection de haute qualité, nous demandons que les contributions respectent les directives suivantes.

• Fournissez un lien vers la page d'accueil de l'application ou du projet . À moins qu'il ne soit extrêmement populaire, il y a une chance que les responsables ne connaissent pas ou n'utilisent pas la langue, le framework, l'éditeur, l'application ou le projet à laquelle votre modification s'applique.

• Fournissez des liens vers la documentation soutenant le changement que vous apportez. La documentation actuelle et canonique mentionnant les fichiers ignorées est la meilleure. Si la documentation n'est pas disponible pour soutenir votre modification, faites de votre mieux pour expliquer à quoi servent les fichiers.

• Expliquez pourquoi vous faites un changement . Même si cela semble évident, veuillez prendre une ou deux phrases pour nous dire pourquoi votre changement ou votre ajout devrait se produire. Il est particulièrement utile de expliquer pourquoi ce changement s'applique à tous ceux qui travaillent avec la technologie applicable, plutôt que vous ou votre équipe.

• Veuillez considérer la portée de votre changement . Si votre modification est spécifique à une certaine langue ou cadre, assurez-vous que la modification est apportée au modèle pour cette langue ou ce framework, plutôt que sur le modèle pour un éditeur, un outil ou un système d'exploitation.

• Veuillez modifier un seul modèle par demande de traction . Cela permet de conserver les demandes de traction et les commentaires axées sur un projet ou une technologie spécifique.

En général, plus vous pouvez faire pour nous aider à comprendre le changement que vous apportez, plus nous serons susceptibles d'accepter votre contribution rapidement.

Modèles versés

Certains modèles peuvent changer considérablement entre les versions, et si vous souhaitez contribuer à ce référentiel, nous devons suivre ce flux spécifique:

• Le modèle à la racine doit être la version prise en charge actuelle
• Le modèle à la racine ne doit pas avoir de version dans le nom de fichier (c'est-à-dire "Evergreen")
• Les versions précédentes des modèles devraient vivre sous community/
• Les versions précédentes du modèle doivent intégrer la version dans le nom de fichier, pour la lisibilité

Cela permet de garantir que les utilisateurs obtiennent la dernière version (car ils utiliseront tout ce qui est à la racine) mais aide les mainteneurs à prendre en charge les anciennes versions encore dans la nature.

Modèles spécialisés

Si vous avez un modèle que vous souhaitez contribuer, mais que ce n'est pas tout à fait grand public, veuillez envisager de l'ajouter au répertoire community sous un dossier qui convient le mieux à sa place.

Les règles de votre modèle spécialisé doivent être spécifiques au cadre ou à l'outil, et tout modèle supplémentaire doit être mentionné dans un commentaire dans l'en-tête du modèle.

Par exemple, ce modèle peut vivre à 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

Tableau de travail contribuant

Voici comment nous vous suggérons de proposer un changement à ce projet:

1. Fourk ce projet sur votre compte.
2. Créez une branche pour le changement que vous avez l'intention de faire.
3. Apportez vos modifications à votre fourchette.
4. Envoyez une demande de traction de la succursale de votre fourche vers notre branche main .

L'utilisation de l'interface Web pour apporter des modifications est également très bien, et vous aidera en fournissant automatiquement le projet et en invitant également à envoyer une demande de traction.

Licence

CC0-1.0.