Pourquoi git ne reconnaît-il pas que mon fichier a été modifié, par conséquent, git add ne fonctionne pas
J'essaye de pousser mes fichiers dans github en utilisant bash. Ils sont déjà là-bas, et je télécharge une version plus récente avec de nouvelles lignes et un nouveau code, etc. Mais quand j'essaie git add et ensuite git status, il dit:
Sur le chef de branche
rien à commettre, répertoire de travail propre
Et le fichier que j'utilise vient d'être modifié.
J'ai eu un problème où il était une fois que je réglais l'index git sur "suppose inchangé" sur mon fichier.
Vous pouvez dire à git de ne plus ignorer les modifications apportées au fichier avec:
git update-index --no-assume-unchanged path/to/file
Si cela ne vous aide pas, un reset peut être suffisant pour d'autres cas étranges.
En pratique, j'ai trouvé la suppression du fichier mis en cache et sa réinitialisation:
git rm --cached path/to/file
git reset path/to/file
git rm --cached signifie uniquement supprimer le fichier de l'index, et reset indique à git de recharger l'index git depuis le dernier commit.
Une autre raison possible (qui s’est avérée vraie dans mon cas actuel). Vérifiez votre fichier .gitignore. Vous pouvez constater que le fichier ou l'extension du fichier avec lequel vous essayez de travailler est inscrit dans .gitignore, ce qui expliquerait pourquoi il n'est pas reconnu comme fichier modifié.
et bien nous n’en avons pas assez pour répondre à cette question, je vais donc vous donner quelques hypothèses:
1) vous avez caché vos modifications, pour corriger le type: git stash pop
2) vous avez eu des modifications et vous les avez validées, vous devriez pouvoir voir votre commit dans git log
3) vous avez eu des modifications faites une sorte de git reset --hard ou autre, vos modifications peuvent être là dans le journal, tapez git reflog --all suivi de la vérification ou de la sélection du ref si vous le trouvez.
4) vous avez extrait le même rapport plusieurs fois et vous vous êtes trompé.
Il y avait un truc génial comme ça. Le plugin git d'Eclipse Kepler marquait automatiquement tous les dossiers de mon projet comme ignorés dans le dossier .gitignore.
Quand j'arrivais à commit dans le menu Team, ils étaient tous réinitialisés pour être ignorés. Autant que je sache, c'était parce que je les avais définies comme dérivées du projet parent. Les annulant en tant que dervied a résolu ce problème. Je n'avais jamais vu cela auparavant sur Indigo. J'espère que ça aide quelqu'un.
J'ai eu un problème similaire en utilisant Sublime Text-3 . Après avoir apporté de nouvelles modifications au code et l’avoir enregistré, lorsque j’ai essayé les commandes git add ./status, la réponse était "branche déjà à jour" . éditeur, le fichier n’a pas été modifié. Ouvrir le fichier dans un autre éditeur et enregistrer les modifications a fonctionné pour moi.
Cela s'est produit sous Windows lors du changement de fichiers en transférant des différences via l'outil WinMerge. Apparemment, WinMerge (du moins sa configuration sur mon ordinateur) ne met parfois pas à jour les horodatages des fichiers qu'il modifie.
Sous Windows, git status , utilise, entre autres choses, l’horodatage du fichier et les modifications de la taille du fichier pour déterminer si un fichier a été modifié ou non. Donc, puisque l'horodatage n'a pas été mis à jour, il ne lui reste que la taille du fichier. Malheureusement, le fichier en question était un fichier de version simple dont le contenu était passé de 7.1.2 à 7.2.0 . En d'autres termes, la taille du fichier est également demeurée inchangée. D'autres fichiers ont également été modifiés par WinMerge et leur horodatage n'a pas été mis à jour, mais leur taille est différente une fois que les modifications ont été détectées pargit status tout va bien.
Lorsque vous modifiez un fichier dans Visual Studio, il apparaît instantanément dans les modifications git, même si le fichier n'est pas enregistré. Il suffit donc de sauvegarder le fichier manuellement (Ctrl + S pour le fichier actuellement affiché ou Ctrl + Shift + S pour tous les fichiers du projet) et Git bash les prendra en charge.
Cela semble fou, mais parfois vous n'êtes pas dans le bon repo, même si vous pensez l'être. Par exemple, vous avez peut-être déplacé le répertoire parent, mais vous avez oublié de changer de mise en pension dans votre éditeur de texte. Ou vice-versa: vous êtes dans le bon référentiel dans l'éditeur de texte mais le mauvais référentiel en ligne de commande. Dans le premier cas, vous apportez vos modifications dans le fichier correct, mais ce n'est pas le même dossier qui est ouvert dans votre ligne de commande, il s'agit donc d'un fichier incorrect. Dans le second cas, vous avez effectivement édité le bon fichier, mais votre git en ligne de commande ne reconnaîtra pas le changement car vous ne vous trouvez pas dans le bon répertoire sur la ligne de commande.
TL; DR; Êtes-vous même sur le bon dépôt?
Mon histoire est un peu drôle, mais je pensais que cela pouvait arriver à quelqu'un qui pourrait avoir un scénario similaire, alors partagez-le ici.
En fait, sur ma machine, j'avais deux référentiels git distincts, repo1 et repo2, configurés dans le même répertoire racine nommé source. Ces deux référentiels sont essentiellement les référentiels de deux produits sur lesquels je travaille par intermittence. Maintenant, le fait est qu’en règle générale, la structure de répertoire du code source de tous les produits est exactement la même dans mon entreprise.
Donc, sans me rendre compte, j'ai modifié exactement le même fichier nommé dans repo2 que j'étais supposé changer dans repo1. Donc, je continuais à exécuter la commande git status sur repo1 et le message restait affiché
Sur le chef de branche
rien à commettre, répertoire de travail propre
pendant une demi-heure. Ensuite, un de mes collègues a observé cela comme une paire d'yeux indépendants et a attiré mon attention sur le fait que je me trouvais dans un entrepôt faux mais très similaire. Au moment où je suis passé à repo1, Git a remarqué les fichiers modifiés.
Cas pas si commun. Mais tu ne sais jamais!
J'ai eu ce problème. Le mien ne fonctionnait pas parce que je mettais mes fichiers dans le dossier .git de mon projet.
Comme cela a déjà été discuté, les fichiers ont probablement été marqués avec "assume-unchanged", ce qui indique à git que vous ne modifierez pas les fichiers, il n'a donc pas besoin de suivre les modifications. Cependant, cela peut affecter plusieurs fichiers et si c'est un grand espace de travail, vous ne voudrez peut-être pas les vérifier tous un par un. Dans ce cas, vous pouvez essayer: git update-index --really-refresh
selon les docs:
Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.
Cela forcera fondamentalement git à suivre les modifications de tous les fichiers sans tenir compte des indicateurs "assumer-non modifié".
En général, avec ce problème, vérifiez d’abord que vous éditez le fichier que vous pensez être! J'ai eu ce problème lorsque je modifiais un fichier JavaScript transpilé au lieu du fichier source (la version transpilée n'était pas sous contrôle de source).
Parfois, cela dépend de la version git et si vous oubliez de faire git add ..
Pour vérifier vos modifications sur le référentiel, utilisez toujours git status qui affiche tous les fichiers non suivis et modifiés. Parce que git diff affiche uniquement les fichiers ajoutés.
Mon client Git (Gitg) a provoqué ce problème pour moi. Les commandes normales que j'exécutais habituellement ne fonctionnaient pas. Même toucher tous les fichiers du projet n'a pas fonctionné.
J'ai trouvé un moyen de le réparer et je ne suis toujours pas sûr de la cause. Copiez le répertoire de votre projet. Les fichiers manquants apparaîtront dans le git status du répertoire copié. Renommer pourrait faire la même chose.
Assurez-vous que not pour créer des liens symboliques (ln -s source dest) à partir de Git Bash pour Windows.
Il ne crée PAS de liens symboliques, mais effectue une copie DEEP de la source vers la destination.
J'ai eu le même comportement que l'OP sur un terminal MINGW64 de Git Bash pour Windows (version 2.16.2) pour me rendre compte que mes modifications "modifiées" étaient en réalité dans le répertoire d'origine et que mes commandes git bash provenaient d'une copie profonde restante inchangé.
J'ai eu le même problème. Il s'avère que j'avais deux copies du projet et que mon terminal était dans le mauvais dossier de projet!
Je me suis plongé dans la question, mais il ne s'agissait que de deux répertoires et je ne savais pas que ces deux répertoires avaient été configurés comme des sous-modules git. Comment cela s’est passé, je n’en ai aucune idée, mais le processus consistait à suivre certaines des instructions sur ce lien, mais PAS à supprimer le répertoire (comme il le fait à la fin), mais plutôt à git add path/to/dir
Quel type de fichier avez-vous essayé de télécharger? Maintenant, je viens de passer presque une heure pour télécharger ma modification CSS. Mais ce css compilé à partir d'un fichier styl a donc été ignoré par git. Quand j'ai changé le styl source, tout a fonctionné.
J'espère que ça aide.
Avez-vous déplacé le répertoire sous votre shell? Cela peut arriver si vous avez restauré votre projet à partir d'une sauvegarde. Pour résoudre ce problème, il suffit de cd aller et retour:
cd ../
cd -