Quand utiliseriez-vous .git / info / exclude au lieu de .gitignore pour exclure des fichiers?

144

Je suis un peu confus quant aux avantages et aux inconvénients de l'utilisation .git/info/excludeet .gitignorede l'exclusion de fichiers.

Les deux sont au niveau du référentiel / projet, alors en quoi diffèrent-ils et quand devrions-nous les utiliser .git/info/exclude?

git gitignore Parag
la source

Réponses:

196

L'avantage de .gitignoreest qu'il peut être archivé dans le référentiel lui-même, contrairement à .git/info/exclude. Un autre avantage est que vous pouvez avoir plusieurs .gitignorefichiers, un dans chaque répertoire / sous-répertoire pour les règles d'ignorer spécifiques au répertoire, contrairement à.git/info/exclude .

Donc, .gitignoreest disponible sur tous les clones du référentiel. Par conséquent, dans les grandes équipes toutes les personnes ignorent le même genre de fichiers Exemple *.db, *.log. Et vous pouvez avoir des règles d'ignorance plus spécifiques en raison de plusieurs .gitignore.

.git/info/excluden'est disponible que pour les clones individuels, par conséquent, ce qu'une personne ignore dans son clone n'est pas disponible dans le clone d'une autre personne. Par exemple, si quelqu'un utilise Eclipsepour le développement, il peut être judicieux pour ce développeur d'ajouter un .builddossier .git/info/excludecar d'autres développeurs n'utilisent peut-être pas Eclipse.

En général, les fichiers / règles d'ignorance qui doivent être universellement ignorés doivent entrer .gitignore, et sinon les fichiers que vous souhaitez ignorer uniquement sur votre clone local doivent entrer dans.git/info/exclude

mu 無
la source
mais cela devrait idéalement aller dans ~ / .gitignore selon la documentation officielle de Git ici, git-scm.com/docs/gitignore
Devendra Swami
@DevendraSwami Je n'ai pas trouvé l'entrée spécifique ~/.gitignoredans votre commentaire ci-dessus. Je crois comprendre que les règles d'ignorance peuvent être à 3 niveaux - $PROJECT/.git/info/excludepour les règles d'ignorer spécifiques (projet, utilisateur), $PROJECT/<any number of directories>/.gitignorequi sont pour les règles d'ignorer spécifiques au projet à travers n'importe quel utilisateur n'importe où (une fois archivées), ~/.gitignore pour les règles d'ignorer spécifiques à l'utilisateur pour tout projet pour cet utilisateur sur cette machine. En fonction de l'objectif, vous choisissez l'endroit où placer une entrée.
mu 無
ouais, tu as absolument raison. Mon commentaire était lié à cette question stackoverflow.com/questions/59673991/…
Devendra Swami
Je m'excuse pour le commentaire original incomplet.
Devendra Swami
2
@ShimmyWeitzhandler, Le fichier sln est-il déjà dans votre dépôt? Exclure ou .ignore n'empêchera pas git de suivre ses modifications. Essayez l'une des solutions suivantes: git rm --cached <path-name>le supprimera du référentiel, mais le conservera localement. git update-index --skip-worktree <path-name>ignorera les modifications apportées au fichier, mais le conservera dans le référentiel. Par curiosité: pourquoi voulez-vous que le fichier sln soit exclu? C'est une partie importante d'une solution .Net, n'est-ce pas?
Koen
36

Googlé: 3 façons d'exclure des fichiers

  1. .gitignore s'applique à chaque clone de ce référentiel (versionné, tout le monde l'aura),
  2. .git/info/exclude s'applique uniquement à votre copie locale de ce référentiel (local, non partagé avec d'autres),
  3. ~/.gitignore s'applique à tous les référentiels de votre ordinateur (locaux, non partagés avec d'autres).

3. nécessite en fait de définir une configuration sur votre ordinateur:

git config --global core.excludesfile '~/.gitignore'
LeGEC
la source
2
Oui, j'ai lu ça aussi, mais je voulais avoir une perspective plus pratique (du monde réel) :-)
Parag
Le blog lié appelle par erreur le fichier .git/info/excludes, alors qu'il devrait l'être .git/info/exclude, comme le confirme la documentation vers laquelle il renvoie.
mwfearnley
13
(spoiler: la troisième façon est d'ignorer globalement par ordinateur via un paramètre dans ~ / .gitconfig)
hmijail pleure les démissions
@hmijail: merci, j'ai inclus votre commentaire dans cette réponse
LeGEC
12

Juste pour offrir notre expérience (du monde réel): nous avons commencé à utiliser .git / info / exclude lorsque nous devions personnaliser certains fichiers de configuration sur chaque environnement de développement, mais nous voulions toujours que la source soit maintenue dans le dépôt et disponible pour d'autres développeurs.

De cette façon, les fichiers locaux, une fois clonés et modifiés, peuvent être exclus des validations sans affecter les fichiers d'origine du dépôt mais sans nécessairement être ignorés dans le dépôt non plus.

Effing
la source
4

À utiliser .gitignorepour ignorer les règles spécifiques au projet . Utilisez excludeou un fichier d'ignorer global pour les règles d'ignorer qui sont spécifiques à votre environnement .

Par exemple, mes fichiers ignorés globaux ignorent les fichiers temporaires générés par l'éditeur que j'utilise - cette règle est spécifique à mon environnement, et peut être différente pour un autre développeur sur le même projet (peut-être qu'ils utilisent un éditeur différent). OTOH, mes .gitignorefichiers de projet ignorent des choses comme les clés d'API et les artefacts de construction - ceux-ci sont pour le projet et devraient être les mêmes pour tout le monde sur le projet.

Est ce que ça aide?

Marnen Laibow-Koser
la source