2010-09-28 2 views
4

Donc. Je suis nouveau à git. Et je pense que j'ai peut-être cassé quelque chose au-delà de ma capacité à réparer (hourra).Messing avec l'histoire GIT a détruit les commits récents ... comment récupérer?

est ici la répartition:

J'ai fait un répertoire distant, et accidentellement inclus certains fichiers très volumineux dans le commit initial. Cela a rendu difficile pour les gens de faire quoi que ce soit avec. (Je ne savais pas au début, et avait apporté des modifications, et avait utilisé le répertoire sur mon propre pendant un certain temps)

j'ai appris que la simple suppression des fichiers et la suppression commiting ne contribue pas avec les gens clonage du répertoire et appris sur la modification de l'histoire grâce à des commandes comme:

git filter-branch --tree-filter 'rm -f public/vidos/*' HEAD 

qui, à ma connaissance, supprimer tous les fichiers du public/VIDOS/répertoire, et de se débarrasser de leur souvenir.

Cela a semblé se produire. Je pouvais cloner les choses avec succès (pas d'erreurs de mémoire), et la copie clonée ne contenait pas les super fichiers. PUIS, ce matin, (après m'être assuré stupidement de faire correspondre exactement le dépositaire à distance (c'est-à-dire de me débarrasser de tous mes trucs locaux, pensant qu'il devrait être à jour pour tout sauf les gros fichiers) le répertoire, et se rendit compte que tous les fichiers semblent être qu'ils étaient sur le chèque initial (pas de modifications, et il y a beaucoup de choses que je MODIFIÉ, font leur apparition)

Je l'ai fait

git log 

pour regarder toutes les modifications, et pourrait voir tous mes commits (y compris les commits qui ont enlevé les super fichiers volumineux du répertoire). n Je l'ai

git reset hashcode 

rollback à la git appropriée (avec le hashcode je suis arrivé du journal).

Sauf que ... même si elle pense que je suis à droite engager, les fichiers sont toujours identiques à ceux que je la première utilisation dans.

je peux regarder en arrière à mon histoire et voir que je n 't filtre-branche sur l'un des fichiers qui sont actuellement non modifiés ... et je suis vraiment confus quant à pourquoi mes changements ne sont plus là. Je me suis engagé ... J'ai poussé ... J'étais à peu près sûr que le dépôt distant avait tous mes changements (il pouvait vérifier (il prendrait une éternité et manquer de mémoire, mais j'obtiendrais les fichiers) et VOIR les changements .. ... mais je ne peux plus les voir

Ai-je fait quelque chose de stupide? Est-ce que je ne suis pas au courant des choses que je ne connaissais pas? Je devrais VRAIMENT obtenir mes modifications en arrière ... répliquer tout ce code (et se souvenir de ce que j'ai même fait) va être très difficile . Y a-t'il quelque chose que je puisse faire?

EDIT:

~~~~~~~~~~~ Ok, remise à zéro n'a pas fonctionné, mais cela:

git checkout hashcode 

semble fonctionner très bien, et je peux voir mon code change. Mais, checkout signifie que je ne suis dans aucune branche, et je ne peux pas les commettre pour être le plus "récent" (il pense qu'il est à jour). Des idées sur comment je peux faire en sorte que cet engagement soit "tête"? Et une fois que c'est la tête, cela va-t-il se débarrasser du filtrage de branche que j'ai fait pour me débarrasser des super gros fichiers? Et si c'est le cas, quelqu'un a-t-il des conseils sur la façon de se débarrasser de ces super gros fichiers SANS ce mal de tête à nouveau.

S'il n'y a pas d'autre moyen, puis-je simplement extraire deux copies (une à la tête, une à ma dernière bonne validation) et manuellement copier et coller les bons fichiers dans la tête, puis valider? On dirait que ça marcherait, mais pas très propre.

+0

Que dit 'git reflog'? Tout non-joignable commet là vous pourriez trouver là? – VonC

+0

il dit: 64e3dcb ... HEAD @ {0}: 64e3dcb92ca80d6d53bb92d9470ca269f73ae044: mise à jour HEAD 7d71565 ... HEAD @ {1}: clone: ​​de [email protected]:/var/git/pcms_vodpop – Jenny

+0

Mais ... um ... J'ai l'impression que c'est si court parce que j'ai bêtement supprimé ma copie locale et l'ai reclassé pour tester si le clonage fonctionnait encore. – Jenny

Répondre

1

Fondamentalement,

git checkout hashcode 

fait ce que je pensais que git reset serait. Je ne sais pas pourquoi les changements ont été annulés quand j'ai filtré, mais maintenant que je peux au moins voir le code, j'ai simplement copié manuellement les changements dans un clone de la tête, puis revérifié les changements à nouveau. Pas la solution la plus élégante, mais je dois garder mon filtrage et avoir le dernier code.

Je pense qu'une partie de ce qui s'est probablement passé était ma compréhension incomplète des dépôts git. Je n'en avais jamais vraiment réussi auparavant, mais j'avais cette notion à moitié imaginée qu'un référentiel git est toujours "à jour", et qu'il a la dernière version des choses. Quand j'ai fait le filtrage des branches, j'étais dans le dépôt git, et j'ai remarqué que les filtres étaient dans l'état git comme devant être validés. Donc j'ai fait. Il est probable que le dépôt n'était pas réellement à jour, et ainsi, en m'engageant (et en jonglant allègrement), j'ai probablement écrasé les changements et essentiellement ramené les choses en arrière.

+0

git reset ne réinitialise que l'index; vous vouliez réinitialiser git --hard. –

Questions connexes