Discussion :

[hbx360]

Bonjour,

Sur un projet de groupe pendant ma formation, j'ai une des personne qui a fait un push. Mais en faisant cela, cela nous a ramené à la version précédente et l'historique, pour une raison qui m'échappe, sur le dépôt distant avait disparu. Je pense qu'il a du zapper un push et donc le pull n'a pas été fait, puis lui a fait un push de l'ancienne version.

Donc j'ai essayé de revenir à un ancien commit en faisant comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git checkout <le numéro de la branche>

Puis, j'ai créé une branche appelé oldCodeBack et après j'ai fait un git reset --hard oldCodeBack.

Ce qui m'amène à cette situation là :

[ image supprimée ]

Et ce que je voulais savoir, c'était comment faire pour ramener la branche oldCodeBack sur origin/main origin/head et que cela devienne donc le dernier commit.

Merci.

[Obsidian]

Bonjour,
Ce n'est pas très difficile en soi. Par contre, ce que tu veux faire exactement au final (et pourquoi vous vous êtes retrouvés dans cette situation) n'est pas très clair. Il faut mettre certaines choses au point avant de te donner une commande toute faite car il est probable qu'en réalité, elle ne soit pas celle qu'il te faut.

Sur un projet de groupe pendant ma formation, j'ai une des personne qui a fait un push. Mais en faisant cela, cela nous a ramené à la version précédente et l'historique, pour une raison qui m'échappe, sur le dépôt distant avait disparu. Je pense qu'il a du zapper un push et donc le pull n'a pas été fait, puis lui a fait un push de l'ancienne version.

Il a sans doute, et surtout, effectué un push -f vers le dépôt, ce qui a justement forcé la branche distante à se positionner sur son dernier commit en date, ce qui est courant et ressemble d'ailleurs à ce que tu veux faire de ton côté. Cela dit, ça reste à vérifier car Github est en général configuré pour interdire cette opération par défaut sur main (ou master).

Quoi qu'il en soit, il est également et malheureusement assez courant de voir les gens se précipiter d'emblée sur les rares options de Git qui permettent précisément de contourner les garde-fous, telles que push -f et reset --hard.

Donc j'ai essayé de revenir à un ancien commit en faisant comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git checkout <le numéro de la branche>

Quel numéro et quelle branche ?

Si c'est la somme SHA1 du commit en question, tu t'es effectivement positionné dessus, mais on ne sait pas encore duquel il s'agit.

S'il était référencé par un nom de branche à ce moment-là, tu t'es effectivement placé au même endroit mais en « mode détaché » : c'est-à-dire au même endroit que la branche sans être officiellement placé dessus, ce qui veut dire que la branche en question ne serait pas mise à jour si jamais tu produisais un nouveau commit depuis cet emplacement.

Puis, j'ai créé une branche appelé oldCodeBack et après j'ai fait un git reset --hard oldCodeBack.

Créer la branche était bien la chose à faire. Par contre, reset --hard ici n'est pas approprié : cela aurait ramené la branche courante à la position indiquée, c'est-à-dire celle occupée par oldCodeBack. Comme tu étais en mode détaché, cela n'a eu aucun effet sur les branches, mais le --hard aura écrasé tout ce qui était éventuellement en suspens dans ton dépôt…

Par d'inquiétude toutefois, si le checkout préalable a fonctionné, c'est que le dépôt était propre au préalable. Mais voila pourquoi il est important de ne pas se précipiter sur les commandes potentiellement destructrices si on ne comprend pas exactement comment elles fonctionnent. C'est d'autant plus vrai que, là encore, le fonctionnement global de la chose n'est pas très compliqué. Par contre, Git ne fonctionne pas tout-à-fait de la même façon que CVS, SVN ou Mercurial. Donc, si ce sont ces modèles-là que l'on a en tête, il est important de les mettre à jour d'abord.

Ce qui m'amène à cette situation là :

[…]

Et ce que je voulais savoir, c'était comment faire pour ramener la branche oldCodeBack sur origin/main origin/head et que cela devienne donc le dernier commit.

Pas clair, là encore : « ramener la branche oldCodeBack sur origin/main », ça signifie « abandonner la position où tu l'as créée et qu'elle pointe actuellement » pour la replacer à l'endroit actuellement référence par « origin/main ». En ce sens, le plus simple consisterait tout simplement à la détruire et à la recréer au bon endroit comme tu l'as fait.

Par contre, à te lire, il semble que tu cherches plutôt à faire en sorte que « origin/main », c'est-à-dire la branche principale du dépôt distant, revienne à la position actuellement repérée par oldCodeBack en abandonnant les derniers commits qui y ont été poussés. Ce qui, en substance, en est exactement l'inverse.

Il est possible de tout modifier, même sans perdre de données à condition de s'y prendre proprement à l'avance, mais cela va impliquer des modifications sur tous les postes qui ont déjà cloné le dépôt, c'est-à-dire ceux de tes collègues. Donc, on va tâcher d'être parfaitement certains de l'objectif à atteindre avant de lancer les travaux.

UPDATE

J'ai cloné votre projet depuis Github (en fonction de ce que je vois dans ta capture d'écran) et il semblerait que tu aies réussi à revenir un cran en arrière avant de poursuivre. Si ce n'est pas ce que tu souhaitais obtenir, il va falloir conserver ce que l'on y voit également.

[hbx360]

Bonjour, désolé pour le retard.

J'ai résolu le problème en faisant un push -f mais j'aurai aimé évité de faire ça. Si tu pouvais me dire comment faire la démarche pour ramener oldCodeBack sur origin/main même en perdant les commits placés en haut. Cela me serait utile pour la prochaine fois.

Merci pour toutes ces info que tu m'as données, c'est vrai que je ne maîtrise pas trop Github et Git mais on progresse avec les erreurs qu'on fait.

PS : je vais supprimer l'image. Je n'avais pas fais gaffe que j'avais des infos dessus.

[Obsidian]

Bonjour, désolé pour le retard.

Pardon pour le retard également. Ton fil méritait que l'on s'y attarde un peu et le travail m'a rattrapé.

PS : je vais supprimer l'image. Je n'avais pas fais gaffe que j'avais des infos dessus.

C'est une bonne chose de l'avoir retirée car elle contenait effectivement des informations potentiellement confidentielles. J'en ai malgré tout conservé une copie, donc on peut s'y référer quand même si nécessaire.

Si tu pouvais me dire comment faire la démarche pour ramener oldCodeBack sur origin/main même en perdant les commits placés en haut. Cela me serait utile pour la prochaine fois.

Encore une fois, il faut être très clair sur ce que tu veux faire exactement : est-ce que tu veux placer oldCodeBack à la position occupée par origin/main (ce que tu demandes ici) ou est-ce que veux forcer le serveur distant, et plus précisément sa branche principale main, à revenir à une position que tu as identifiée et que tu repères temporairement par oldCodeBack (ce qui est exactement le contraire de ce que tu demandes mais serait plus proches de tes attentes et semble correspondre à ce que tu as fait sur ton serveur) ?

Considérons qu'il s'agit du deuxième cas.

Il faut se souvenir que « origin/main » et, d'une manière générale, toutes les branches « remote » d'un dépôt ne sont que les consignations locales de la position des branches des autres dépôts connus du tien, et qu'elles ne sont mises à jour que lorsque tu te mets en relation avec ces dépôts, soit pour les mettre à jour explicitement avec « git remote update », par exemple, ou lors d'un « git fetch », d'un « git pull » ou d'un « git push » car leur mise à jour est nécessaire pour poursuivre les opérations.

Donc, modifier en local la position de « origin/main » n'a pas de sens en soi : il faut s'arranger pour que le dépôt distant (le serveur) revienne d'abord lui-même à la position souhaitée, puis mettre les références à jour dans ton dépôt local.

J'ai résolu le problème en faisant un push -f mais j'aurai aimé évité de faire ça.

Tu es obligé d'y recourir si tu veux forcer le retour de origin/main à une ancienne position existante, car cela implique de réécrire l'histoire : sans cette possibilité, la seule approche propre (et techniquement possible si -f est désactivé) consiste à considérer tous les commits existants comme actés puis soumettre de nouveaux commits annulant les effets des précédents, comme lorsque l'on abroge une loi. C'est notamment ce à quoi sert git revert et cela permet de conserver un historique compatible avec celui qui a déjà été récupéré par les autres participants.

Si tu veux vraiment faire du nettoyage, tu as le droit de recourir à push -f quand même si c'est sur ton propre dépôt mais il faut alors avertir toutes les personnes qui ont cloné ton dépôt que tu l'as fait, si elles ne sont pas encore assez familières avec Git pour s'en rendre compte d'elles-mêmes et prendre les bonnes mesures en conséquence.

Si tu ne le fais pas, au prochain git pull de leur côté, Git va avoir l'impression que ce sont leurs propres branches locales qui sont en avance et ne se rendra pas compte que c'est en fait la branche principale qui est revenue en arrière. Si en plus, tu publies de nouveaux commits pour remplacer ceux que tu as supprimés, alors Git pensera que la branche main a divergé par rapport à un ancêtre commun, entre la version du serveur et celle du collaborateur, ce qui est a priori normal quand on travaille chacun dans son coin sur une même branche. Lors d'un git pull, il va alors essayer de fusionner les deux branches divergentes pour les réunir à nouveau en une seule branche commune, sans se rendre compte qu'il est en fait en train de mélanger les anciens et les nouveaux commits.

[hbx360]

D'accord je vois, je te remercie d'avoir pris le temps de me répondre. Je marque en résolue.