Notre équipe de développement utilise GIT et nous avons perdu des modifications aux fichiers au moins deux fois récemment. Nous utilisons des repos github privés.
Dans l'affaire en cours, nous pouvons remonter les journaux sur Github et voir des mises à jour que j'ai faites dans un fichier. Plus tard, un autre membre de l'équipe a modifié une autre partie du dossier et il semble avoir détruit mes modifications. Je les ai toujours localement.
a autre personne qui a vécu cela? Toute cause ou solutions?
Je ne suis pas
9 Réponses :
Bien que je ne puisse pas parler à votre problème spécifique, ce que je peux dire, c'est que hier, j'ai vécu quelque chose de très similaire. J'avais un concepteur de concepteur avec des URL dans le code et mettez à jour des images dans une application iPhone, je me suis terminée et je ne m'en ai pas parlé. J'ai poussé mes changements que j'avais faits qui ont également touché certains de ces fichiers (des endroits différents), et il a rejeté comme une avance rapide non locale. Alors j'ai tiré, j'ai eu des conflits, les résolva et poussé. Problème résolu. Cependant, j'ai annulé ses changements de code dans le processus.
Une chose que j'ai récemment ajoutée à mon flux de travail en raison d'un problème très similaire à celui que j'ai expérimenté hier, sur un repo privé GitHub; est de cacher mes changements, je suis sur le point de commettre, tirer du repo et appliquer ma cachette. Devrait-il y avoir des conflits, résoudre ceux-ci, puis pousser.
Bonne idée, mais votre flux de travail signifie que vous ne pouvez pas vous engager plusieurs fois entre les cygles de tirage / poussées. Quelqu'un m'a dit que vous pouvez utiliser "git tire-tire -rebase" pour résoudre le même problème, mais je ne sais pas quelles implications qui ont sur l'histoire et que je me méfie de rebasing en général (au moins en ce moment, peut-être parce que je n'ai peut-être pas t comprendre ça).
P.s. - Je ne dis pas que tu as tort, je dis juste qu'il y a un inconvénient. :)
@jer: Je pense que votre solution est fondamentalement la même chose que la reconvie
Une chose similaire est arrivée à mon équipe aussi.
Leçon apprise: lorsque vous tirez, vous devriez faire attention à la fusion des conflits. S'il y a des conflits sur Pull, Git ne commet pas de modifications fusionnées dans votre repo local et Si vous n'avez pas de conflits dans la fusion sur Tir - aucun problème avec des changements perdus ne surviennent. Parce que Git récupère, fusionne et s'engage à votre copie locale et "pousser" puis propage ces modifications fusionnées à distance.
Je ne suis pas complètement certain de cela, mais je pense qu'après un conflit de fusion, si vous ne validez que les fichiers conflictuels (ou tout autre sous-ensemble des modifications), le reste des modifications sera perdue. C'est très probablement ce qui s'est passé dans mon cas, un collègue de collègue le fit avec la fusion.
J'ai eu des problèmes similaires où dans le journal général, je peux voir les modifications que j'ai apportées dans un fichier, mais lorsque je vérifie le journal spécifique du fichier, ces changements ne figurent pas, seulement ceux de mon collègue. Je suis à peu près sûr que c'est parce que mon collègue a gâché la fusion en quelque sorte ... mais je souhaite toujours que cela apparaisse dans le journal.
Je voudrais ajouter mes quelques mots. J'ai récemment remarqué un comportement très étrange dans Git. Mon équipe avait de gros problèmes à cause de cela. Je ne sais pas comment c'est arrivé mais il semble que l'histoire dans mon repo soit incohérente.
Petit illustration:
commettre xxxxxxxxx:
ligne "bar" a été ajouté au fichier FOO.
... Travail en cours ...
beaucoup de commettre plus tard (disons environ 100):
ligne "bar" n'existe plus dans ce fichier !!
Enquête:
1.J'ai inspecté Historique du fichier avec:
Git journal foo et gitk foo
J'ai même comparé des blob consécutifs de chaque commit avec l'outil externe (GVIMDIFF).
C'est une chose intéressante que j'ai trouvé deux commits (appelons-les aaa et zzz).
BLOB DE FICHIER FOO à partir de GIGITY AAAA consistait "Bar" mais Blob de Zzz n'a pas fait.
Quand j'ai inspecté les commissocies de ces commits avec Gitk (et Gitweb), j'ai remarqué qu'il n'y a aucune opération de "bar" de la ligne dans Zzz.
Est-il possible qu'il y ait eu des engagements entre deux et dissous dans l'air mince?
Ou peut-être commettre Zzz vient de supprimer mon outil de ligne et DIFF intégré à git (ou gitk) est cassé?
2.Je cherche des commits qui pourraient supprimer cette ligne avec "Git Log -s", quelque chose comme:
GIT LOG -S'BAR '- FOO
Il s'avère que cette ligne n'a jamais été supprimée. En fait, il a été ajouté deux fois. Première fois où il a été introduit au projet et au deuxième fois où il a été ajouté à nouveau en tant que bugs urgent.
J'aime vraiment utiliser Git et même persuadé quelques amis à l'utiliser, mais si ce type de magie continue à se produire, je devrai commencer à chercher des alternatives.
C'est un bon exemple de ce que j'ai rencontré récemment, mais ce n'est pas une réponse. Ce serait bien si cela a été posté comme une question.
Je suis confronté à ce même problème.
Je suppose qu'il existe une configuration différente entre les prisonniers, peut-être que quelqu'un manque une configuration Autocrlf.
Git est en quelque sorte considère que deux révisions sont complètement différentes du même fichier, écrasant ainsi l'ancienne avec de nouveaux changements d'une autre branche.
Si une fusion à trois voies (par défaut récursif) trouve deux enfants complètement différents (c'est-à-dire à cause de la configuration erronée de la CRLF), le résultat fusionné sera le plus récent, sans conflit.
Nous avons eu le même problème: Dev A a fait un changement. Dev B a apporté un changement à quelque chose d'autre. Après Dev B a poussé ses modifications, le changement de Dev A Dev A Made "a disparu". Le changement que Dev B a fait il y a des semaines, mais il semblait que personne n'avait remarqué la perte de changements de Dev A jusqu'à maintenant.
La vraie raison Le changement "a disparu" était que l'outil que nous utilisions pour voir l'historique (TFS) montre une version incorrecte de l'histoire. Lorsque nous avons regardé avec différents outils (SmartGit and Sourcetree), nous avons vu ce qui s'est réellement passé: quelqu'un avait écrasé le changement tout en essayant de réparer un conflit de fusion et l'écrasement était là dans une vue claire.
Donc, ce n'était pas git qui perdait des changements, c'était l'outil que nous utilisions nous donnant une fausse vue de l'histoire. Juste quelque chose à regarder.
Nous utilisons GIT depuis un an et 99% du temps que quelque chose a «mal tourné» avec Git, c'était en fait causé par une personne qui n'a pas vraiment compris Git. La seule fois qu'il "était git" était une question de la CRLF, mais c'est vraiment parce que nous ne savions pas assez bien la git et (grâce à tellement), il était facile à gérer.
Alors, regardez toujours soigneusement et vous trouverez probablement le problème se résume à quelqu'un qui ne comprend pas Git et de faire quelque chose qu'ils ne devraient pas avoir.
Dans mon cas, j'ai étalé mes changements pour travailler sur une bogue d'urgence et j'ai simplement oublié de m'installer et de les engager
J'ai réussi à reproduire une instance de cela dans Visual Studio.
Dans l'écran de résolution de conflit dans VS, une fois que vous avez fini de choisir les modifications des deux branches,
eu ce problème et a trouvé ce qui suit Snippet a aidé à analyser:
git log -20 --date=iso --pretty=format:'%cd %h %d'
Comment le membre de la teammember a-t-il ses changements commis et poussé? Je doute que GIT soit "Perdre" des données. Je pense qu'il est plus probable que quelqu'un ait fait quelque chose comme ne pas fusionner des changements et et juste prendre leurs changements ...
Si vous inspectez chacun des diffs entre les versions, vous verrez probablement les modifications précédentes étant retournées. C'est la cause la plus courante de perte de données causée par des personnes qui font de mauvaises commettes. Un visualiseur de révision GIT ou un front de git graphique peut aider à les suivre.
@hvgotcodes - Il dit qu'il fait "commettre, tirer, pousser." Donc, vous dites que lorsqu'il y a des conflits de fusion, il peut simplement dire "je gagne?"
Tirez sur --rebase Est-ce que une Rebase et unrégulier fusionne-t-il une fusion. Peut-être que c'est juste un conflit de fusion?