À moins qu'un dépôt ne soit composé de plusieurs projets indépendants, il semble qu'il serait plus simple de n'avoir qu'un seul .gitignorefichier à la racine du dépôt que plusieurs à travers. Existe-t-il une meilleure pratique standard sur cette analyse ou sur une analyse en ligne du moment où une approche est meilleure que l'autre?
Réponses:
Je peux penser à au moins deux situations où vous voudriez avoir plusieurs .gitignorefichiers dans différents (sous) répertoires.
Différents répertoires ont différents types de fichiers à ignorer. Par exemple, le .gitignoredans le répertoire supérieur de votre projet ignore les programmes générés, tandis que la Documentation/.gitignoredocumentation générée est ignorée.
Ignorez les fichiers donnés uniquement dans le (sous-) répertoire donné (vous pouvez cependant les utiliser /sub/foodans .gitignore).
N'oubliez pas que les modèles dans le .gitignorefichier s'appliquent récursivement au répertoire (sous) où se trouve le fichier et à tous ses sous-répertoires, à moins que le modèle ne contienne '/' (par exemple, le modèle names'applique à tout fichier nommé namedans le répertoire donné et à tous ses sous-répertoires, tandis qu'il /names'applique au fichier avec ce nom uniquement dans le répertoire donné).
Documentation/**/*.html(notez que toute barre oblique ancre le modèle; le /fooest utilisé pour ancrer le fichier directement dans le répertoire)
Comme note tangentielle, un cas où la possibilité d'avoir plusieurs .gitignorefichiers 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. Mettez simplement un octet .gitignore(contenant un seul astérisque) dans ce répertoire et il n'apparaîtra jamais dans git statusetc.
printf \* > .gitignore(le nettoyage est automatique lorsque vous supprimez le répertoire). Je suis certain qu'il y a des situations où .git/info/excludec'est le choix le plus approprié, mais pas beaucoup.
Vous pouvez en 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 -- afile.
Et vous pouvez avoir une version différente d'un .gitignorefichier par branche: j'ai déjà vu ce type de configuration pour s'assurer qu'une branche ignore un fichier tandis que l'autre branche ne le fait pas: voir cette question par exemple .
Si votre référentiel comprend plusieurs projets indépendants, il serait préférable de les référencer comme sous-modules .
Ce serait les meilleures pratiques réelles, permettant à chacun de ces projets d'être cloné indépendamment (avec leurs .gitignorefichiers respectifs ), tout en étant référencé par une révision spécifique dans un projet parent global.
Voir la vraie nature des sous-modules pour en savoir plus.
Notez que, depuis git 1.8.2 (mars 2013), vous pouvez faire un git check-ignore -v -- yourfilepour voir à quel gitignore s'exécuter (à partir de quel .gitignorefichier) est appliqué à ' yourfile', et mieux comprendre pourquoi ce fichier est ignoré.
Voir " quelle gitignorerègle ignore mon fichier? "
Pro single
Facile à trouver.
La recherche de règles d'exclusion peut être assez difficile si j'ai plusieurs gitignores, à plusieurs niveaux dans le repo.
Avec plusieurs fichiers, vous vous retrouvez généralement avec un peu de duplication.
Pro multiple
Étend la "connaissance" à la partie de l'arborescence de fichiers où elle est nécessaire.
Étant donné que Git ne suit que les fichiers, un .gitignore vide est le seul moyen de valider un répertoire "vide".
(Et avant Git 1.8, la seule façon d'exclure un motif comme my/**.exampleétait de créer my/.gitignoreavec le motif **.foo. Cette raison ne s'applique pas maintenant, comme vous pouvez le faire /my/**/*.example.)
Je préfère de loin un seul fichier, où je peux trouver toutes les exclusions. Je n'ai jamais manqué .svn par répertoire, et je ne manquerai pas non plus .gitignore par répertoire.
Cela dit, plusieurs gitignores sont assez courants. Si vous les utilisez, soyez au moins cohérents dans leur utilisation pour les rendre raisonnables à utiliser. Par exemple, vous pouvez les placer dans des répertoires à un seul niveau de la racine.
emptyd'ailleurs) est plus courant.
Il existe de nombreux scénarios dans lesquels vous souhaitez engager un répertoire à votre repo Git mais sans les fichiers qu'il contient , par exemple logs, cache, uploadsrépertoires , etc.
Donc, ce que je fais toujours, c'est d'ajouter un .gitignorefichier dans ces répertoires avec le contenu suivant:
*
!.gitignore
Avec ce .gitignorefichier, Git ne suivra aucun fichier dans ces répertoires mais me permet toujours d'ajouter le .gitignorefichier et donc le répertoire lui-même au dépôt.