À moins qu'un dépôt ne soit composé de plusieurs projets indépendants, il semble plus simple d'avoir un seul fichier .gitignore à la racine du dépôt que plusieurs fichiers dispersés. Existe-t-il une meilleure pratique standard à ce sujet ou une analyse en ligne sur quand une approche est meilleure que l'autre?
Je peux penser à au moins deux situations où vous voudriez avoir plusieurs fichiers .gitignore dans différents (sous)-répertoires.
Différents répertoires ont différents types de fichiers à ignorer. Par exemple, le .gitignore dans le répertoire principal de votre projet ignore les programmes générés, tandis que Documentation/.gitignore ignore la documentation générée.
Ignorer les fichiers donnés uniquement dans un (sous)-répertoire donné (vous pouvez utiliser /sous/foo dans .gitignore, cependant).
N'oubliez pas que les modèles dans le .gitignore s'appliquent de manière récursive au répertoire (sous) dans lequel se trouve le fichier et à tous ses sous-répertoires, sauf si le modèle contient '/' (donc par exemple le modèle nom s'applique à tout fichier nommé nom dans le répertoire donné et tous ses sous-répertoires, tandis que /nom s'applique au fichier portant ce nom uniquement dans le répertoire donné).
Ah, pour une raison quelconque, je pensais que /Documentation/*.html couvrirait cela, mais je suppose que le * joker ne correspondra qu'aux répertoires à un seul niveau.
@ConleyOwens : avec Git moderne, vous pouvez utiliser Documentation/**/*.html (notez que tout slash ancre le motif; le /foo est utilisé pour ancrer le fichier directement dans le répertoire)
Troisième scénario : .gitignore généré à partir de par exemple yarn : Il est plus facile de le laisser là où il a été généré, d'autant plus que l'outil de génération peut le modifier davantage lors d'une mise à jour ou d'un changement de configuration.
En passant, un cas où la possibilité d'avoir plusieurs fichiers .gitignore est très utile est si vous voulez un répertoire supplémentaire dans votre copie de travail que vous n'avez jamais l'intention de valider. Il vous suffit de mettre un .gitignore d'1 octet (contenant juste un astérisque) dans ce répertoire et il ne s'affichera jamais dans git status, etc.
Bien sûr, si cela ne vous dérange pas la complexité de devoir ouvrir un fichier dans un emplacement quelque part en dehors de la racine du dépôt, puis d'écrire un chemin complet dedans, et ensuite de se souvenir de nettoyer l'entrée si/quand vous supprimez le répertoire. Comparez cela avec printf \* > .gitignore (le nettoyage est automatique lorsque vous supprimez le répertoire). Je suis certain qu'il existe des situations où .git/info/exclude est le choix le plus approprié, mais pas beaucoup.
Vous pouvez avoir plusieurs .gitignore, chacun bien sûr dans son propre répertoire.
Pour vérifier quelle règle gitignore est responsable d'ignorer un fichier, utilisez git check-ignore: git check-ignore -v -- un_fichier.
Et vous pouvez avoir différentes versions d'un fichier .gitignore par branche: j'ai déjà vu ce type de configuration pour s'assurer qu'une branche ignore un fichier tandis que l'autre ne le fait pas: voir cette question par exemple.
Si votre dépôt inclut plusieurs projets indépendants, il serait préférable de les référencer en tant que sous-modules.
Cela serait les bonnes pratiques réelles, permettant à chacun de ces projets d'être cloné indépendamment (avec leurs fichiers .gitignore respectifs), tout en étant référencés par une révision spécifique dans un projet parent global.
Voir la véritable nature des sous-modules pour en savoir plus.
Notez que, depuis git 1.8.2 (mars 2013) vous pouvez exécuter un git check-ignore -v -- votrefichier afin de voir quelle règle gitignore (de quel fichier .gitignore) est appliquée à 'votrefichier', et mieux comprendre pourquoi ledit fichier est ignoré.
Voir "quelle règle de gitignore ignore mon fichier?"
Pro single
Facile à trouver.
La recherche des règles d'exclusion peut être assez difficile si j'ai plusieurs fichiers gitignore, à plusieurs niveaux dans le dépôt.
Avec plusieurs fichiers, vous vous retrouvez également généralement avec pas mal de redondances.
Pro multiple
Limite la "connaissance" à la partie de l'arborescence de fichiers où elle est nécessaire.
Puisque Git ne suit que des fichiers, un .gitignore vide est le seul moyen de commettre un répertoire "vide".
(Et avant Git 1.8, le seul moyen d'exclure un modèle comme my/**.exemple était de créer my/.gitignore avec le modèle **.foo. Cette raison ne s'applique plus maintenant, car vous pouvez faire /my/**/*.exemple.)
Je préfère beaucoup un seul fichier, où je peux trouver toutes les exclusions. Je n'ai jamais regretté le .svn par répertoire, et je ne regretterai pas non plus le .gitignore par répertoire.
Cela dit, les multiples gitignores sont assez courants. Si vous les utilisez, au moins soyez cohérent dans leur utilisation pour les rendre logiques à utiliser. Par exemple, vous pouvez les placer dans des répertoires à un seul niveau de la racine.
Il existe de nombreux scénarios où vous souhaitez commettre un répertoire dans votre dépôt Git sans les fichiers qu'il contient, par exemple les répertoires logs, cache, uploads etc.
Donc ce que je fais toujours est d'ajouter un fichier .gitignore dans ces répertoires avec le contenu suivant:
# ce répertoire est intentionnellement ignoré
/*
!/.gitignoreAvec ce fichier .gitignore, Git ne suivra aucun fichier dans ces répertoires mais me permettra quand même d'ajouter le fichier .gitignore et donc le répertoire lui-même dans le dépôt.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
