Comment ignorer les fichiers d’un répertoire dans Git?

Quelle est la syntaxe appropriée du fichier .gitignore pour ignorer les fichiers d’un répertoire?

Serait-ce

 config/databases.yml cache/* log/* data/sql/* lib/filter/base/* lib/form/base/* lib/model/map/* lib/model/om/* 

ou

 /config/databases.yml /cache/* /log/* /data/sql/* /lib/filter/base/* /lib/form/base/* /lib/model/map/* /lib/model/om/* 

?

FORMAT DE MOTIF

  • Une ligne vide ne correspond à aucun fichier, elle peut donc servir de séparateur pour la lisibilité.

  • Une ligne commençant par # sert de commentaire.

  • Un préfixe facultatif ! ce qui annule le modèle; tout fichier correspondant exclu par un modèle précédent sera à nouveau inclus. Si un motif négatif correspond, cela remplacera les sources de motifs de priorité inférieure.

  • Si le motif se termine par une barre oblique, il est supprimé pour les besoins de la description suivante, mais il ne trouvera qu’une correspondance avec un répertoire. En d’autres termes, foo/ correspondra à un répertoire foo et à des chemins situés en dessous, mais ne correspondra pas à un fichier régulier ou à un lien symbolique foo (ceci est cohérent avec le fonctionnement de pathspec en général dans git).

  • Si le modèle ne contient pas de barre oblique / , git le traite comme un modèle de shell global et recherche une correspondance avec le chemin d’access par rapport à l’emplacement du fichier .gitignore (par rapport au niveau supérieur de l’arborescence, sinon d’un .gitignore fichier).

  • Sinon, git considère le modèle comme un object global pouvant être consommé par fnmatch(3) avec l’indicateur FNM_PATHNAME : les caractères génériques du motif ne correspondront pas à un / dans le chemin d’access. Par exemple, Documentation/*.html Documentation/git.html correspond à Documentation/git.html mais pas à Documentation/ppc/ppc.html ou à tools/perf/Documentation/perf.html .

  • Une barre oblique correspond au début du chemin. Par exemple, /*.c correspond à cat-file.c mais pas à mozilla-sha1/sha1.c

Vous pouvez en trouver plus ici

git help gitignore
ou
man gitignore

Ce serait le premier. Aller par les extensions aussi bien au lieu de la structure des dossiers.

C’est-à-dire que mon exemple de développement C # ignore le fichier:

 #OS junk files [Tt]humbs.db *.DS_Store #Visual Studio files *.[Oo]bj *.user *.aps *.pch *.vspscc *.vssscc *_i.c *_p.c *.ncb *.suo *.tlb *.tlh *.bak *.[Cc]ache *.ilk *.log *.lib *.sbr *.sdf ipch/ obj/ [Bb]in [Dd]ebug*/ [Rr]elease*/ Ankh.NoLoad #Tooling _ReSharper*/ *.resharper [Tt]est[Rr]esult* #Project files [Bb]uild/ #Subversion files .svn # Office Temp Files ~$* 

Mettre à jour

Je pensais fournir une mise à jour des commentaires ci-dessous. Bien que ne répondant pas directement à la question de l’OP, reportez-vous à la section suivante pour plus d’exemples de syntaxe .gitignore .

Wiki de la communauté (constamment mis à jour):

.gitignore pour les projets et solutions Visual Studio

Vous trouverez plus d’exemples d’utilisation de langage spécifique (merci au commentaire de Chris McKnight):

https://github.com/github/gitignore

Les chemins contenant des barres obliques sont relatifs au répertoire contenant le fichier .gitignore – généralement le niveau supérieur de votre référentiel, bien que vous puissiez également les placer dans des sous-répertoires.

Donc, puisque dans tous les exemples que vous donnez, les chemins contiennent des barres obliques, les deux versions sont identiques. Le seul moment où vous devez mettre une barre oblique est quand il n’y en a pas déjà un. Par exemple, pour ignorer foo uniquement au niveau supérieur du référentiel, utilisez /foo . Ecrire simplement foo ignorera tout ce qui est appelé foo n’importe où dans le repository.

Vos caractères génériques sont également redondants. Si vous souhaitez ignorer un répertoire entier, appelez-le simplement:

 lib/model/om 

La seule raison d’utiliser des caractères génériques comme vous l’avez si vous avez l’intention de ne plus tenir compte de quelque chose dans le répertoire:

 lib/model/om/* # ignore everything in the directory !lib/model/om/foo # except foo 

Une barre oblique indique que l’entrée ignore doit uniquement être valide par rapport au répertoire dans lequel réside le fichier .gitignore. Spécifier *.o ignorerait tous les fichiers .o de ce répertoire et tous les sous-répertoires, tandis que /*.o ignorerait simplement dans ce répertoire, tandis que /*.o les ignorerait seulement dans /foo/*.o .

Si vous souhaitez placer un fichier .gitignore au niveau supérieur et le rendre compatible avec tous les dossiers situés en dessous, utilisez /**/ .

Par exemple, pour ignorer tous les fichiers *.map dans un dossier /src/main/ et les sous-dossiers:

 /src/main/**/*.map 

Les deux exemples de la question sont en fait de très mauvais exemples pouvant entraîner une perte de données!

Mon conseil: ne jamais append /* aux répertoires dans les fichiers .gitignore, sauf si vous avez une bonne raison!

Une bonne raison serait par exemple ce que Jefromi a écrit: “si vous avez l’intention de ne plus tenir compte de quelque chose dans le répertoire” .

La raison pour laquelle cela ne devrait pas être fait est que l’ajout de /* aux répertoires fonctionne d’une manière telle qu’il ignore correctement tout le contenu du répertoire, mais qu’il a un effet secondaire dangereux:

Si vous exécutez git stash -u (pour stocker temporairement des fichiers suivis et non-suivis) ou git clean -df (pour supprimer des fichiers non suivis mais gardés ignorés) dans votre référentiel, tous les répertoires ignorés avec un ajout /* seront définitivement supprimés !

Un peu de fond

Je devais apprendre cela à la dure. Quelqu’un dans mon équipe ajoutait /* à certains répertoires de notre .gitignore. Au fil du temps, j’ai eu des occasions où certains répertoires ont soudainement disparu. Répertoires contenant des gigaoctets de données locales nécessaires à notre application. Personne ne pouvait l’expliquer et j’ai toujours le droit de télécharger à nouveau toutes les données. Au bout d’un moment, j’ai eu la notion que cela pourrait avoir à faire avec git stash . Un jour, je voulais nettoyer mon repo local (tout en gardant les fichiers ignorés) et j’utilisais git clean -df et à nouveau mes données avaient disparu. Cette fois-ci j’en ai eu assez et j’ai enquêté sur le problème. J’ai finalement compris que la raison en est le ajouté /* .

Je suppose que cela peut s’expliquer par le fait que le directory/* ignore tout le contenu du répertoire mais pas le répertoire lui-même. Ainsi, il n’est pas considéré comme suivi ou ignoré lorsque les choses sont supprimées. Même si l’ git status et l’ git status git status --ignored donnent une image légèrement différente.

Comment reproduire

Voici comment reproduire le comportement. J’utilise actuellement Git 2.8.4.

Un répertoire appelé localdata/ contenant un fichier factice ( important.dat ) sera créé dans un repository git local et le contenu sera ignoré en plaçant /localdata/* dans le fichier .gitignore . Lorsque l’une des deux commandes git mentionnées est exécutée maintenant, le répertoire sera (de manière inattendue) perdu.

 mkdir test cd test git init echo "/localdata/*" >.gitignore git add .gitignore git commit -m "Add .gitignore." mkdir localdata echo "Important data" >localdata/important.dat touch untracked-file 

Si vous faites un git status --ignored ici, vous obtiendrez:

 On branch master Untracked files: (use "git add ..." to include in what will be committed) untracked-file Ignored files: (use "git add -f ..." to include in what will be committed) localdata/ 

Maintenant soit faire

 git stash -u git stash pop 

ou

 git clean -df 

Dans les deux cas, le répertoire soi-disant ignoré localdata sera parti!

Je ne sais pas si cela peut être considéré comme un bug, mais je suppose que c’est au moins une fonctionnalité dont personne n’a besoin.

Je vais le rapporter à la liste de développement git et voir ce qu’ils en pensent.

Ce serait:

 config/databases.yml cache log data/sql lib/filter/base lib/form/base lib/model/map lib/model/om 

ou même éventuellement:

 config/databases.yml cache log data/sql lib/*/base lib/model/map lib/model/om 

Au cas où ce filter et cette form seraient les seuls répertoires de lib à avoir un sous base répertoire de base qui doit être ignoré (voir comme exemple de ce que vous pouvez faire avec les astérisques).

Le premier. Ces chemins de fichiers sont relatifs à l’emplacement de votre fichier .gitignore.

Je maintiens un service basé sur une interface graphique et une interface graphique qui vous permet de générer des modèles .gitignore très facilement sur https://www.gitignore.io .

Vous pouvez soit taper les modèles de votre choix dans le champ de recherche, soit installer l’alias de la ligne de commande et exécuter

$ gi swift,osx

Un exemple de fichier .gitignore peut ressembler à un fichier ci-dessous pour un projet Android Studio

 # built application files *.apk *.ap_ # files for the dex VM *.dex # Java class files *.class # generated files bin/ gen/ # Local configuration file (sdk path, etc) local.properties #Eclipse *.pydevproject .project .metadata bin/** tmp/** tmp/**/* *.tmp *.bak *.swp *~.nib local.properties .classpath .settings/ .loadpath YourProjetcName/.gradle/ YourProjetcName/app/build/ */YourProjetcName/.gradle/ */YourProjetcName/app/build/ # External tool builders .externalToolBuilders/ # Locally stored "Eclipse launch configurations" *.launch # CDT-specific .cproject # PDT-specific .buildpath # Proguard folder generated by Eclipse proguard/ # Intellij project files *.iml *.ipr *.iws .idea/ /build build/ */build/ */*/build/ */*/*/build/ *.bin *.lock YourProjetcName/app/build/ .gradle /local.properties /.idea/workspace.xml /.idea/libraries .DS_Store .gradle/ app/build/ *app/build/ # Local configuration file (sdk path, etc) local.properties /YourProjetcName/build/intermediates/lint-cache/api-versions-6-23.1.bin appcompat_v7_23_1_1.xml projectFilesBackup build.gradle YourProjetcName.iml YourProjetcName.iml gradlew gradlew.bat local.properties settings.gradle .gradle .idea android build gradle