101 votes

Ai-je perdu mes modifications après le rebasement ?

J'ai récemment rebasé une branche sur laquelle je travaillais. L'histoire de l'arbre ressemblait à quelque chose comme ceci :

1 = 2 = 3 = 4
     \
      5 = 6 = 7
           \
            8

Je voulais rebaser mes changements (numéro 8 dans le diagramme) pour être sur la branche master (jusqu'au commit 4 sur le diagramme maintenant). J'ai donc fait ce qui suit :

git checkout my_branch
git rebase master

< beaucoup de git mergetool/git rebase --skip pour résoudre les conflits >

Seulement maintenant, quand je cours :

git checkout my_branch
git diff master

Je n'obtiens aucune différence. Je n'ai pas perdu ma branche (je peux toujours recréer mes modifications à partir d'un patch que j'ai sauvegardé) mais je ne trouve pas la fusion/rebase que j'ai effectuée. Qu'est-ce que j'ai fait de mal ? Le rebasement est-il toujours présent quelque part avec mes modifications fusionnées avec le master ou dois-je le refaire ?

227voto

jszakmeister Points 8323

Si vous ne voyez aucune différence, je pense que vous avez perdu vos modifications. Vous pouvez probablement utiliser git reflog pour identifier la branche qui existait avant le rebasement, et utiliser git reset --hard <my-branch-tip-before-rebase> pour retrouver la branche d'origine. Et oui, vous devrez recommencer le processus :-(

Je ne sais pas vraiment comment vous avez fait pour qu'elles soient identiques. Je me serais attendu à voir ce qui suit avec la commande que vous avez donnée :

1 = 2 = 3 = 4              (master)
     \       \
      \       5' = 6' = 8' (my_branch)
       \
        5 = 6 = 7

Dans ce cas, vous auriez probablement dû utiliser rebase --onto :

git rebase --onto master <commit id for 6> my_branch

Cela vous aurait laissé avec un graphique ressemblant à ceci :

1 = 2 = 3 = 4              (master)
     \       \
      \       8'           (my_branch)
       \
        5 = 6 = 7

En ce qui concerne la perte de vos modifications, il faut un peu de pratique pour gérer les conflits de fusion, surtout lorsque vous avez deux grands blocs qui semblent presque identiques. J'ai toujours recours à l'examen de la différence réelle introduite par un commit, et j'essaie d'extraire cette modification et de la fusionner avec ce qui se trouve déjà sur la branche de manière appropriée. Je peux facilement voir comment votre changement a pu se perdre là-dedans.

Une chose à retenir. Si vous ne vous attendez pas à un tas de conflits de fusion - parce que vous ne pensez pas que les sources divergent suffisamment - le fait d'en voir un est un signal d'alarme indiquant que vous faites quelque chose de mal. Il est bon de faire marche arrière, en faisant un git rebase --abort en examinant les branches et en vérifiant à nouveau si vous vous attendez à un conflit. Assurez-vous de prendre note de l'endroit où le conflit s'est produit (il y a généralement un "Applying ..." juste avant que rebase ne vous renvoie à la ligne de commande). C'est généralement un bon point de départ.

Parfois, les conflits sont inévitables et il est fastidieux de les résoudre. Mais je pense qu'avec la pratique, vous rencontrerez moins ce problème.

Pour plus d'informations sur le repiquage des changements entre les branches, consultez le document git rebasement page de manuel. Cherchez "rebase --onto". Le premier résultat devrait vous amener à une section traitant de la transplantation des changements dans une autre branche.

Prograide.com

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.

Powered by:

X