Réponses:
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
~/.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.
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?
Googlé: 3 façons d'exclure des fichiers
.gitignore s'applique à chaque clone de ce référentiel (versionné, tout le monde l'aura),.git/info/exclude s'applique uniquement à votre copie locale de ce référentiel (local, non partagé avec d'autres),~/.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'
.git/info/excludes, alors qu'il devrait l'être .git/info/exclude, comme le confirme la documentation vers laquelle il renvoie.
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.
À 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?