git rebase --continue ne fonctionnera pas
J'ai fait git rebase master, a corrigé les conflits signalés dans un fichier, puis git add le fichier pour résoudre le conflit. Ensuite, j'ai fait git rebase --continue, et j'ai obtenu ceci:
Application: test unitaire fixe
Aucun changement - avez-vous oublié d'utiliser 'git add'? S'il n'y a plus rien à mettre en scène, il y a de fortes chances que quelque chose d'autre ait déjà introduit les mêmes changements; vous voudrez peut-être ignorer ce correctif.
Une fois ce problème résolu, exécutez "git rebase --continue". Si vous préférez ignorer ce correctif, exécutez plutôt "git rebase --skip". Pour vérifier la branche d'origine et arrêter le rebasage, exécutez "git rebase --abort".
Une idée de ce qui me manque ici? Dois-je faire git rebase --skip?
Si vous êtes sous Mac OS X, vous devez d'abord désactiver revisiond, car cela peut perturber les fichiers de votre arborescence de travail au milieu de la rebase, provoquant un comportement imprévisible et cassé:
git config --global core.trustctime false
Le problème est expliqué dans cet article , et un grand merci à @ nickfalk qui l'a signalé.
Quant à votre rebase, ce genre de situation n'est pas inhabituel dans la pratique. Essayons de réfléchir aux étapes de ce qui se passe:
Lorsque vous rebasez la branche actuelle au-dessus d'une autre branche, git déplace le HEAD vers l'autre branche, et commence à appliquer les validations uniques que vous avez dans votre branche actuelle.
En rejouant l'un de ces commits, vous avez atteint un conflit. Vous l'avez résolu, mais en conséquence, il n'y a aucun changement à valider, rien à rejouer dans ce commit.
En pratique, cela signifie que vous avez rejeté les modifications de la validation en cours en cours de relecture. Donc, si vous n'avez besoin de rien de ce commit, il est normal de le sauter. Donc git rebase --skip est logique ici.
Respirez, vous ne devenez pas fou! ; - = C'est un bug connu où OSX (si c'est bien ce que vous utilisez) joue avec git, il est détaillé ici (pas par moi).
L'histoire courte (c'est-à-dire le correctif) est:
git config --global core.trustctime false
J'ai eu un problème similaire dans mon projet et résolu en plaçant l'option - preserve-merges dans la commande rebase. Dans mon projet, ce problème était dû à un commit de fusion, qui est un "commit vide". En utilisant git rebase --preserve-merges il prend le commit de fusion et continue la fusion sans casser l'arborescence de commit.
Cela pourrait bien signifier que les changements sont déjà rebasés. Vérifiez simplement l'état de git.
Aucune des suggestions ci-dessus n'a fonctionné. J'ai découvert que j'avais ce problème parce que j'avais effectué une réinitialisation matérielle de la branche principale, tandis que ma branche de fonctionnalité avait des validations principales héritées (ne me demandez pas comment - aucune idée :().
J'ai copié mes modifications dans un répertoire temporaire, supprimé ma branche de fonctionnalité, les ai recopiées et redémarré à partir de zéro. Moche mais efficace. Non recommandé si vous essayez de conserver plusieurs validations dans votre branche de fonctionnalité. Non suggéré sauf si vous avez essayé TOUT AUTRE.