git ignorer vs. exclure vs. supposer-inchangé

J'ai lu les documents à ce sujet plusieurs fois et je ne comprends toujours pas complètement les différences entre ces différentes commandes. Peut-être que c'est juste moi, mais la documentation pourrait être plus lucide:

Http://git-scm.com/docs/gitignore

Https://help.github.com/articles/ignoring-files

De plus, une grande partie du commentaire sur ce sujet semble utiliser les mots "indexé", "engagé", "suivi" un peu vaguement, ce qui rend le les différences entre ces trois moins claires.

Ma compréhension actuelle (certes limitée):

  • Les fichiers correspondants dans .gitignore ne seront pas suivis à l'avenir. (Bien qu'ils aient été suivis précédemment. Cela signifie qu'ils n'apparaîtra jamais dans une future liste git status telle que modifiée. cependant, les modifications futures seront toujours synchronisées avec les repos distants . En d'autres termes, les fichiers sont toujours "indexé", mais ils ne sont pas "suivi". Parce qu'un fichier .gitignore se trouve dans répertoire du projet, le fichier lui-même peut être versionnés.

  • Les fichiers correspondants dans .git/info/exclude ne seront pas non plus "suivis". Dans en outre, ces fichiers ne seront jamais synchronisés à distance, et donc ne jamais être vu sous quelque forme que ce soit par d'autres utilisateurs. Ces fichiers doivent être des fichiers qui sont spécifiques à l'éditeur ou au flux de travail d'un seul utilisateur. Parce qu'il est dans le .git le fichier exclude ne peut pas lui-même être versionné.

  • Les fichiers qui ont fait fonctionner assume-unchanged sur eux n'apparaissent pas non plus dans git status ou git diff. Cela semble similaire à exclude, en ce sens que ces fichiers ne sont ni "indexés " ni"suivis". Cependant, la dernière version du fichier à valider avant assume-unchanged restera visible pour tous les utilisateurs du repo.

Mes questions:

  1. L'interprétation ci-dessus est-elle correcte? Merci de me corriger.

  2. Si un fichier a déjà été dans un commit, Quelle est la fonction différent entre le faire correspondre dans .exclude et l'exécution assume-unchanged dessus? Pourquoi on préfère une approche de l'autre?

  3. Mon cas d'utilisation de base est que je veux éviter de trier les diffs sur fichiers compilés, mais je veux toujours que ces fichiers compilés soient synchronisés les fichiers source. Un fichier gitignore'd sera-t-il toujours poussé? Sinon, comment gérer le déploiement final des fichiers compilés?

Merci d'avance pour toute aide.

47
demandé sur Ben 2014-04-16 05:24:25

4 réponses

Je vais accepter cette réponse envoyée par courrier électronique de Junio Hamano (le responsable de Git) parce que je pense qu'elle explique certaines choses plus lucidement que les documents officiels, et elle peut être considérée comme un conseil "officiel":

Le .gitignore et .git / info / exclude sont les deux interfaces utilisateur pour appeler le même mécanisme. Dans l'arborescence .gitignore doivent être partagés entre le projet les membres (c.-à-d. tous ceux qui travaillent sur le projet devraient les chemins qui correspondent au modèle ignorer là-dedans comme trucs). Sur l'autre main, .git / info / exclude est destiné aux modèles d'ignorer personnels (c'est-à-dire vous, tout en travaillant sur le projet, les considérer comme cruft).

Assume-unchanged ne doit pas être abusé pour un mécanisme ignore. Il est "Je sais que mes opérations sur le système de fichiers sont lentes. Je promets à Git que je ne changera pas ces chemins en les faisant avec ce bit - - - de cette façon, Git n'a pas à vérifier si j'ai changé les choses là-dedans chaque fois que je demande pour git "statut " sortie". Cela ne signifie pas autre chose que cela. Surtout, c'est Pas Une promesse de Git que Git considérera toujours ces chemins ne sont pas modifiés - - - si Git peut déterminer un chemin qui est marqué comme supposer-inchangé a changé sans encourir supplémentaire lstat (2) coût, il se réserve le droit de signaler que le chemin a été modifié (par conséquent, "git commit-a" est libre de valider ce changement).

57
répondu Ben 2016-09-16 18:50:22

Ajout de Junio Hamano de réponse, Git 2.3.0 (février 2015) maintenant supprime à partir de la gitignore documentation

pour ignorer les modifications non validées dans un fichier déjà suivi, utilisez ' git update-index --assume-unchanged'.

Voir commettre 936d2c9 à partir de Michael J Gruber (mjg):

gitignore.txt: ne pas suggérer assume-unchanged

git-update-index --assume-unchanged n'a jamais été destiné à ignorer les modifications apportées aux fichiers suivis ( les statistiques).
Donc, ne le suggérez pas comme un moyen d'y parvenir.

7
répondu VonC 2017-05-23 11:33:26

Espérons que pas trop de sources d'information utilisent suivi, indexé et engagé vaguement, car ils sont tous différents et significatifs.

  • indexé signifie que le fichier est dans l'index git. À un moment donné dans le passé, quelqu'un a use git add ou une commande équivalente sur le fichier. Le fichier est suivi et peut également être validé.
  • Suivi signifie que git surveille le fichier pour les modifications. Tout fichier validé ou tout fichier de l'index est suivi.
  • engagés signifie que le fichier est dans l'historique de git. Il y a au moins un point de contrôle pour ce fichier; vous pouvez revenir à n'importe quelle version validée du fichier.

Maintenant à la limite de mes connaissances. Je ne suis pas sûr de cette définition, mais c'est ma compréhension; heureux d'être corrigé à ce sujet:

Lorsqu'un fichier indexé est validé, il n'est plus dans l'index. La prochaine fois qu'il est modifié (ou supprimé), il est de retour dans l'index. l'indice est la somme de tous les suivis fichiers qui diffèrent de ce qui est commis .

L'index est également appelé le cache, ou la zone de transfert.

Passons à votre question principale. .git/info/exclure est le même que .gitignore, juste une priorité inférieure et pas dans le référentiel (donc, pas commis et partagé). Ni affecte les fichiers déjà suivis. Les deux affectent les fichiers qui ne sont pas actuellement suivis. Mettre .gitignore après git add ou git commit est trop tard; git suit déjà le fichier, et .gitignore n'affectera pas que.

Assume-unchanged affecte uniquement les fichiers suivis, et est donc complètement séparé de .gitignore. Il peut temporairement prétendre que le fichier est non suivi et ignoré (mais il n'a pas à le faire et ne peut rien faire de différent du comportement normal). Comme le mentionnent d'autres réponses, cela n'est pas utilisé pour ignorer les modifications apportées aux fichiers, juste pour éviter potentiellement les opérations du système de fichiers sur les systèmes de fichiers lents.

Re: point 3: vous ne devriez pas ajouter de fichiers compilés à git. Compilez vos fichiers à un répertoire différent que votre source est dans, et ignorer ce répertoire entier. Regroupez vos fichiers compilés dans une bibliothèque et ajoutez-les à un référentiel d'artefacts, mais ne les mettez pas dans git.

3
répondu Paul Hicks 2015-08-27 21:36:50

Je pense que la différence de .gitignore et d'assumer inchangé sont

  1. .gitignore peut être partagé avec d'autres personnes dans l'équipe, mais supposons-inchangé doit être configuré pour chaque membre individuellement.

  2. Supposons-inchangé sont des fichiers suivis. C'est très utile si un fichier contient des informations de configuration mais peut être modifié par l'équipe. Si un fichier est défini comme assume-unchanged mais modifié par d'autres personnes et poussé vers le référentiel distant, git rappellera quand essayer de tirez à partir de la télécommande.

1
répondu guest 2014-07-09 21:11:03