tl;dr : L'approche correcte devrait être : git rm --cached logs/xx.log, puis mettre à jour .gitignore en ignorant le fichier cible, et enfin git commit -m "We really don't want Git to track this anymore!"
Les raisons spécifiques sont les suivantes :
Bien que la réponse acceptée puisse atteindre l'objectif (temporaire), ce n'est pas l'approche la plus correcte. Cela méconnaît le sens de git update-index, et les conséquences les plus directes (indésirables) de cela sont les suivantes :
Tous les membres de l'équipe doivent s'exécuter sur le fichier cible : git update-index --assume-unchanged <PATH>. En effet, même si vous laissez Git faire semblant de ne pas voir les modifications apportées au fichier cible, le fichier lui-même est toujours dans l'historique de Git, donc tous les membres de l'équipe appliqueront les modifications apportées au fichier cible lorsque fetch est exécuté. . (Mais en fait, le fichier cible ne veut pas du tout être enregistré par Git, plutôt que de faire semblant de ne pas le voir changer)
Une fois que quelqu'un a modifié le fichier cible et directement git update-index --assume-unchanged <PATH>push sans , alors tous les membres qui ont extrait le dernier code doivent réexécuter update-index , sinon Git recommencera à enregistrer les modifications apportées au fichier cible. C'est en fait très courant. Par exemple, si un membre change de machine ou de disque dur et clone une nouvelle base de code, puisque le fichier cible est toujours dans l'historique Git, il est susceptible d'oublier . 🎜>mise à jour-index.
Pourquoi cela se produit-il ? La réponse se trouve dans les pages de manuel de Git :
Tout d'abord, la définition de git update-index est :
Enregistrer le contenu du fichier dans l'arborescence de travail dans l'index (Enregistrer le contenu du fichier dans l'espace de travail dans la zone d'index)
Le sens implicite de cette phrase est : update-index cible les fichiers enregistrés dans la base de données Git, et non les fichiers qui doivent être ignorés.
Ensuite, regardez quelques descriptions connexes sur --assume-unchanged :
Lorsque le bit "supposer inchangé" est activé, Git arrête de vérifier les fichiers de l'arborescence de travail pour d'éventuelles modifications, vous devez donc désactiver manuellement le bit pour indiquer à Git lorsque vous modifiez le fichier de l'arborescence de travail. Ceci est parfois utile lorsque vous travaillez avec. un gros projet sur un système de fichiers qui a un appel système lstat(2) très lent (par exemple cifs).
signifie en gros :
Après avoir appliqué cet indicateur, Git cesse de rechercher les modifications possibles dans les fichiers de l'espace de travail. Vous devez donc manuellement réinitialiser l'indicateur afin que Git sache que vous souhaitez reprendre le suivi des modifications des fichiers. Cela peut être utile lorsque vous travaillez sur un grand projet lorsque l'appel système lstat du système de fichiers est très lent.
Nous savons que Git n'est pas seulement utilisé pour la gestion des versions de code, mais que de nombreux projets dans d'autres domaines utilisent également Git. Par exemple, l'un des projets d'un client de notre entreprise impliquait la gestion de versions de documents de dessin de pièces de précision, et ils utilisaient également Git. Un scénario d'utilisation consiste à modifier certains fichiers volumineux, mais chaque fois que Git l'enregistre, il doit calculer les modifications apportées au fichier et mettre à jour l'espace de travail. Ce délai est très évident lorsque le disque dur est lent.
L'utilisation réelle de
git update-index --assume-unchanged est la suivante :
Vous modifiez un fichier volumineux, vous devriez le git update-index --assume-unchanged d'abord, afin que Git ignore temporairement vos modifications apportées au fichier
;
Lorsque votre travail est terminé et prêt à être soumis, réinitialisez l'indicateur de modification : git update-index --no-assume-unchanged, afin que Git n'ait besoin de le mettre à jour qu'une seule fois, ce qui est tout à fait acceptable
;
Soumettre + pousser.
De plus, selon une description plus détaillée dans la documentation :
Cette option peut également être utilisée comme mécanisme grossier au niveau du fichier pour ignorer les modifications non validées dans les fichiers suivis (un peu comme ce que fait .gitignore pour les fichiers non suivis).
Cette description nous apprend deux faits :
Bien qu'elle puisse être utilisée pour obtenir le résultat souhaité par l'affiche, ce n'est pas une approche raffinée (grossière)
;
La même chose doit être accomplie en utilisant des fichiers .gitignore (pour les fichiers non suivis).
La question qui se pose est : Pourquoi ai-je ajouté les règles dans .gitignore mais cela n'a eu aucun effet ?
C'est parce que nous avons mal compris le but du fichier .gitignore, qui ne peut être utilisé que sur des Fichiers non suivis, c'est-à-dire ceux qui n'ont jamais été été enregistrés par les fichiers Git (fichiers qui n'ont jamais été ajoutés ou validés depuis leur ajout).
La raison pour laquelle votre règle ne prend pas effet est que ces .log fichiers ont été enregistrés par Git, donc .gitignore est complètement invalide pour eux. C'est exactement ce que fait la réponse courte au début :
Supprimer le suivi du fichier de la base de données Git
Écrivez les règles correspondantes dans .gitignore pour que l'ignorance prenne effet
;
Soumettre + pousser.
Ce n'est qu'en faisant cela que tous les membres de l'équipe seront cohérents sans effets secondaires, et seulement en faisant cela, les autres membres de l'équipe n'auront pas besoin de faire de travail supplémentaire pour maintenir l'ignorance des modifications apportées à un fichier.
Une dernière chose à noter, git rm --cached supprime le statut de suivi, pas le fichier physique si vous ne le souhaitez vraiment pas du tout, vous pouvez aussi directement rm+ignorer+soumettre.
Pour les fichiers qui ont été maintenus, même l'ajout de gitignore n'aidera pas.
Utilisez la commande suivante : git update-index --assume-unchanged logs/*.log
De cette façon, les fichiers sous logs n'apparaîtront pas à chaque fois que vous soumettez
Donnez-moi une réponse détaillée
.gitignore ne peut ignorer que les fichiers qui n'ont pas été suivis à l'origine. Si certains fichiers ont été inclus dans la gestion des versions, la modification de .gitignore n'est pas valide.
L'approche correcte consiste à configurer manuellement chaque entrepôt cloné pour ne pas vérifier les modifications apportées à des fichiers spécifiques.
De plus, git fournit également une autre méthode d'exclusion pour faire la même chose. La différence est que le fichier .gitignore lui-même sera soumis au référentiel. Utilisé pour enregistrer les fichiers publics qui doivent être exclus. Et .git/info/exclude définit ici les fichiers que vous devez exclure localement. Il n’affectera personne d’autre. Il ne sera pas soumis au référentiel.
.gitignore a également une petite fonction intéressante. Un fichier .gitignore vide peut être utilisé comme espace réservé. Cela devient utile lorsque vous devez créer un répertoire de journaux vide pour votre projet. Vous pouvez créer un répertoire de journaux et y placer un fichier .gitignore vide. De cette façon, lorsque vous clonez ce dépôt, git créera automatiquement un répertoire de journaux vide.
J'ai trouvé que la réponse avec le plus grand nombre de votes (n͛i͛g͛h͛t͛i͛r͛e͛) ne comprenait pas du tout la question Au lieu de cela, la réponse de @FatGhosta est la bonne réponse
Si vous suivez la méthode de n ͛i ͛ g ͛ h ͛ t ͛i ͛ r ͛e ͛ , cela obtiendra simplement "Supprimez le fichier qui n'a pas besoin d'être enregistré de git tout en conservant le fichier localement et ignorez à l'avenir, il commit" au lieu d'atteindre "Ignorer les fichiers qui existent déjà dans git lors de la validation"
En fait, la scène devrait être comme ceci. Il existe un fichier de configuration, tel que les informations de lien de la base de données Les informations de lien de chacun ne sont certainement pas les mêmes, mais un modèle standard doit être fourni pour indiquer comment procéder. remplissez les informations du lien Ensuite, il existe une situation où vous devez enregistrer un fichier de configuration standard sur git, puis chacun configure une copie des informations du lien pour son propre usage en fonction de ses propres circonstances spécifiques, mais ne soumet pas les informations du lien. fichier de configuration à la bibliothèque Par conséquent, la réponse de FatGhosta est la bonne pour cette question Réponse
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
tl;dr : L'approche correcte devrait être :
git rm --cached logs/xx.log, puis mettre à jour.gitignoreen ignorant le fichier cible, et enfingit commit -m "We really don't want Git to track this anymore!"Les raisons spécifiques sont les suivantes :
Bien que la réponse acceptée puisse atteindre l'objectif (temporaire), ce n'est pas l'approche la plus correcte. Cela méconnaît le sens de
git update-index, et les conséquences les plus directes (indésirables) de cela sont les suivantes :Tous les membres de l'équipe doivent s'exécuter sur le fichier cible :
git update-index --assume-unchanged <PATH>. En effet, même si vous laissez Git faire semblant de ne pas voir les modifications apportées au fichier cible, le fichier lui-même est toujours dans l'historique de Git, donc tous les membres de l'équipe appliqueront les modifications apportées au fichier cible lorsque fetch est exécuté. . (Mais en fait, le fichier cible ne veut pas du tout être enregistré par Git, plutôt que de faire semblant de ne pas le voir changer)Une fois que quelqu'un a modifié le fichier cible et directement
git update-index --assume-unchanged <PATH>push sans , alors tous les membres qui ont extrait le dernier code doivent réexécuter update-index , sinon Git recommencera à enregistrer les modifications apportées au fichier cible. C'est en fait très courant. Par exemple, si un membre change de machine ou de disque dur et clone une nouvelle base de code, puisque le fichier cible est toujours dans l'historique Git, il est susceptible d'oublier . 🎜>mise à jour-index.Pourquoi cela se produit-il ? La réponse se trouve dans les pages de manuel de Git :
Tout d'abord, la définition de git update-index est :
Le sens implicite de cette phrase est : update-index cible les fichiers enregistrés dans la base de données Git, et non les fichiers qui doivent être ignorés.
Ensuite, regardez quelques descriptions connexes sur --assume-unchanged :
signifie en gros :
Nous savons que Git n'est pas seulement utilisé pour la gestion des versions de code, mais que de nombreux projets dans d'autres domaines utilisent également Git. Par exemple, l'un des projets d'un client de notre entreprise impliquait la gestion de versions de documents de dessin de pièces de précision, et ils utilisaient également Git. Un scénario d'utilisation consiste à modifier certains fichiers volumineux, mais chaque fois que Git l'enregistre, il doit calculer les modifications apportées au fichier et mettre à jour l'espace de travail. Ce délai est très évident lorsque le disque dur est lent.
L'utilisation réelle degit update-index --assume-unchangedest la suivante :git update-index --assume-unchangedd'abord, afin que Git ignore temporairement vos modifications apportées au fichiergit update-index --no-assume-unchanged, afin que Git n'ait besoin de le mettre à jour qu'une seule fois, ce qui est tout à fait acceptableDe plus, selon une description plus détaillée dans la documentation :
Cette description nous apprend deux faits :
.gitignore(pour les fichiers non suivis).La question qui se pose est : Pourquoi ai-je ajouté les règles dans .gitignore mais cela n'a eu aucun effet ?
C'est parce que nous avons mal compris le but du fichier .gitignore, qui ne peut être utilisé que sur des Fichiers non suivis, c'est-à-dire ceux qui n'ont jamais été été enregistrés par les fichiers Git (fichiers qui n'ont jamais été ajoutés ou validés depuis leur ajout).
La raison pour laquelle votre règle ne prend pas effet est que ces
.logfichiers ont été enregistrés par Git, donc.gitignoreest complètement invalide pour eux. C'est exactement ce que fait la réponse courte au début :Ce n'est qu'en faisant cela que tous les membres de l'équipe seront cohérents sans effets secondaires, et seulement en faisant cela, les autres membres de l'équipe n'auront pas besoin de faire de travail supplémentaire pour maintenir l'ignorance des modifications apportées à un fichier.
Une dernière chose à noter,
git rm --cachedsupprime le statut de suivi, pas le fichier physique si vous ne le souhaitez vraiment pas du tout, vous pouvez aussi directementrm+ignorer+soumettre.Pour les fichiers qui ont été maintenus, même l'ajout de gitignore n'aidera pas.
Utilisez la commande suivante :
git update-index --assume-unchanged logs/*.logDe cette façon, les fichiers sous logs n'apparaîtront pas à chaque fois que vous soumettez
Donnez-moi une réponse détaillée
.gitignore ne peut ignorer que les fichiers qui n'ont pas été suivis à l'origine. Si certains fichiers ont été inclus dans la gestion des versions, la modification de .gitignore n'est pas valide.
L'approche correcte consiste à configurer manuellement chaque entrepôt cloné pour ne pas vérifier les modifications apportées à des fichiers spécifiques.
De plus, git fournit également une autre méthode d'exclusion pour faire la même chose. La différence est que le fichier .gitignore lui-même sera soumis au référentiel. Utilisé pour enregistrer les fichiers publics qui doivent être exclus. Et .git/info/exclude définit ici les fichiers que vous devez exclure localement. Il n’affectera personne d’autre. Il ne sera pas soumis au référentiel.
.gitignore a également une petite fonction intéressante. Un fichier .gitignore vide peut être utilisé comme espace réservé. Cela devient utile lorsque vous devez créer un répertoire de journaux vide pour votre projet. Vous pouvez créer un répertoire de journaux et y placer un fichier .gitignore vide. De cette façon, lorsque vous clonez ce dépôt, git créera automatiquement un répertoire de journaux vide.
Supprimez le fichier journal, ajoutez-le et validez à nouveau
J'ai trouvé que la réponse avec le plus grand nombre de votes (n͛i͛g͛h͛t͛i͛r͛e͛) ne comprenait pas du tout la question
Au lieu de cela, la réponse de @FatGhosta est la bonne réponse
Si vous suivez la méthode de n ͛i ͛ g ͛ h ͛ t ͛i ͛ r ͛e ͛ , cela obtiendra simplement
"Supprimez le fichier qui n'a pas besoin d'être enregistré de git tout en conservant le fichier localement et ignorez à l'avenir, il commit"
au lieu d'atteindre
"Ignorer les fichiers qui existent déjà dans git lors de la validation"
En fait, la scène devrait être comme ceci. Il existe un fichier de configuration, tel que les informations de lien de la base de données
.Les informations de lien de chacun ne sont certainement pas les mêmes, mais un modèle standard doit être fourni pour indiquer comment procéder. remplissez les informations du lien
Ensuite, il existe une situation où vous devez enregistrer un fichier de configuration standard sur git, puis chacun configure une copie des informations du lien pour son propre usage en fonction de ses propres circonstances spécifiques, mais ne soumet pas les informations du lien. fichier de configuration à la bibliothèque
Par conséquent, la réponse de FatGhosta est la bonne pour cette question Réponse