J'essaie de pousser mes fichiers vers github en utilisant bash. Ils y sont déjà, et je télécharge une version plus récente avec de nouvelles lignes, du code, etc. Mais lorsque j'essaie git add et ensuite git status il est dit :
Sur la branche master
rien à commettre, répertoire de travail propre
Et le fichier que j'utilise vient d'être modifié.
Nous n'avons pas assez d'éléments pour répondre à cette question, je vais donc vous donner plusieurs pistes :
1) vous avez caché vos modifications, pour corriger le type : git stash pop
2) vous aviez des modifications et vous les avez validées, vous devriez pouvoir voir votre validation dans git log
3) vous avez eu des changements qui ont fait une sorte de git reset --hard ou autre, vos modifications peuvent être présentes dans le reflog, tapez git reflog --all puis en vérifiant ou en sélectionnant la référence si vous la trouvez.
4) vous avez vérifié le même dépôt plusieurs fois, et vous êtes dans le mauvais dépôt.
J'ai eu une mauvaise configuration du sous-module Git. Je suis allé à la racine du répertoire et j'ai lancé ces commandes sur les répertoires qui avaient .git dossiers précédemment :
git rm --cached sub/directory/path -fEnsuite, les répertoires sont apparus dans git status .
Vous pouvez faire une copie de votre dépôt avant d'essayer, au cas où.
Cela s'est produit sous Windows lors de la modification de fichiers en transférant les différences via l'outil WinMerge. Apparemment, WinMerge (du moins la façon dont il est configuré sur mon ordinateur) ne met pas toujours à jour l'horodatage des fichiers qu'il modifie.
Sous Windows, git status utilise, entre autres, l'horodatage d'un fichier et les changements de taille du fichier pour déterminer si un fichier a été modifié ou non. Comme l'horodatage n'a pas été mis à jour, il ne peut se baser que sur la taille du fichier. Malheureusement, le fichier en question était un simple fichier de version dont le contenu a changé de 7.1.2 a 7.2.0 . En d'autres termes, la taille du fichier est également restée inchangée. D'autres fichiers qui ont également été modifiés par WinMerge et dont l'horodatage n'a pas été mis à jour mais dont la taille était différente après la modification ont été détectés par git status très bien.
J'ai eu un truc funky comme ça qui s'est produit. Le plugin git d'Eclipse Kepler marquait automatiquement tous les dossiers de mon projet comme étant ignorés dans le dossier .gitignore.
Quand je suis arrivé à commit sur le Team menu, ils se remettaient tous à ignorer. Pour autant que je puisse dire, c'est parce que je les avais définis comme dérivés dans le projet parent. En les désignant comme dervied J'ai réparé ça. Je n'avais jamais vu ça avant sur Indigo. J'espère que ça aidera quelqu'un.
TL;DR ; Êtes-vous au moins sur le bon référentiel ?
Mon histoire est un peu drôle mais j'ai pensé que cela pouvait arriver à quelqu'un qui pourrait avoir un scénario similaire, alors je la partage ici.
En fait, sur ma machine, j'avais deux dépôts git distincts. repo1 y 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 dans mon entreprise. Le problème 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 m'en rendre compte, j'ai modifié un fichier exactement du même nom dans repo2 que je devais changer en repo1 . Donc, j'ai juste continué à lancer la commande git status sur repo1 et il a continué à donner le même message
Sur la branche master
rien à commettre, répertoire de travail propre
pendant une demi-heure. Un de mes collègues l'a alors observé comme une paire d'yeux indépendante et m'a fait remarquer que j'étais dans un dépôt erroné mais très similaire. Au moment où j'ai basculé vers repo1 Git a commencé à remarquer les fichiers modifiés.
Un cas pas si fréquent. Mais on ne sait jamais !
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
