TortoiseGit: Rebase with conflict

Question

Je pense que je fais quelque chose de mal mais je ne sais pas où. J'ai une branche de travail et une branche principale. La branche de travail a quelques commits qui ne sont pas encore sur la branche principale. Maintenant, j'ai une correction critique que je m'engage à maîtriser. Je veux aussi avoir ce commit dans la branche de travail, donc j'utilise rebase.

J'ouvre la fenêtre de rebasage dans TortoiseGit et il montre celui-ci commettre. Après avoir cliqué sur "Start Rebase", il m'informe que plusieurs conflits sont survenus. Je corrige les conflits et appuie sur "Valider" dans la fenêtre de rebasage.

Maintenant, le commit apparaît dans le journal de validation. Bien. Mais quand je veux le pousser au serveur, on m'informe que HEAD est détaché. Je résous cela avec git checkout -b temp et pousse cette branche provisoire.

Si je récupère maintenant à partir de l'origine et que j'ouvre à nouveau la fenêtre de rebasage, le commit que je viens de repasser apparaît de nouveau pour rebase. Je pense qu'il ne devrait pas apparaître là car il a déjà été rebasé.

J'ai également vérifié lors d'un commit sans conflit, il n'apparaît plus dans la fenêtre de rebasage.

Qu'est-ce que je fais mal?

Answer 1

Lorsque vous utilisez l'interface de ligne de commande: après la fixation d'un conflit de rebasage, vous devez vous engager, puis dire git « poursuivre les actions restantes du rebasage courant »:

git rebase --continue 

Je ne sais pas ce TortoiseGit fait ou ne fait pas, si vous avez une action qui pourrait ressembler à « continuer rebasage », ou « reprendre rebasage », ou ...

---

une autre chose au sujet de rebasage: git ne garde pas suivi des validations qui ont déjà été rebasées,
à la place, il regarde le correctif introduit par chaque validation pour être rebasé, et analyse la branche cible pour voir si un commit applique déjà le même correctif. En cas de conflit, vous modifiez généralement quelque chose dans le correctif résultant, de sorte que le re-rebasage ne détecte pas que la validation initiale a bien été appliquée et que le commit réapparaît.

Une façon d'éviter ce problème est de fusionnermaster en branch, au lieu de rebasage.