Ich versuche einen Ast auf den Master zu bringen, etwas, das ich schon tausend Mal gemacht habe. Aber heute funktioniert es nicht:
%Vor%Alles beginnt wie normal, aber Git beendet die Rebase, ohne irgendwelche meiner Commits dort zu setzen; Meine Filiale meinst endet auf dem gleichen Commit wie Master.
Die naheliegende Schlussfolgerung wäre, dass meine Commits schon irgendwo im Meister sind. Aber sie sind nicht , ich schwöre es. Ich bin durch die Geschichte gegangen. Die Commits sind in einigen anderen Feature-Zweigen, aber sie sind nirgendwo in der Geschichte von Master. (Und ich kann sagen, dass sie sich sowieso nicht im Master befinden, wenn der Master ausgecheckt ist.)
Also, wenn die Commits nicht bereits in meinem Upstream-Verlauf sind, warum sonst würde git rebase das Stacken meiner Commits an der Spitze verweigern?
Seltsamerweise, wenn ich die Commits auf Master eins nach dem anderen auslese, funktioniert das. Und dann kann ich meinen mystuff-Zweig zum Ende bewegen und wieder dorthin zurückmelden, wo er war. (Aber warum sollte ich es so machen?)
BEARBEITEN :
Die Dokumentation zu git rebase sagt dies:
Der aktuelle Zweig wird auf
<upstream>oder<newbase>zurückgesetzt, wenn die Option--ontoangegeben wurde. Dies hat den gleichen Effekt wiegit reset --hard <upstream>(oder<newbase>).ORIG_HEADwird vor dem Zurücksetzen auf die Spitze des Zweigs gesetzt.Die Commits, die zuvor im temporären Bereich gespeichert wurden, werden nacheinander nacheinander auf den aktuellen Zweig angewendet. Beachten Sie, dass alle Commits in
HEAD, die dieselben textuellen Änderungen wie ein Commit inHEAD..<upstream>einleiten, ausgelassen werden (d. H. Ein Patch, der bereits mit einer anderen Commit-Nachricht oder einem anderen Timestamp upstream akzeptiert wurde, wird übersprungen).
Dies wäre konsistent mit dem Verhalten, das ich sehe wenn die Commits tatsächlich upstream existierten ... aber sie nicht. Und wie in den Kommentaren erwähnt, funktioniert git rebase master korrekt und wendet alle Commits an. Aber git rebase ohne master funktioniert nicht, obwohl Master als der Upstream-Zweig eingestellt ist.
Konfiguration meiner Filialen:
%Vor% Das hat mich nach einem gewissen Git-Upgrade mindestens ein Dutzend Mal gebissen. Dort ist jetzt ein Unterschied zwischen git rebase und git rebase master : Ersteres wurde geändert, um die gleiche "Gabel-Punkt" -Maschinerie zu verwenden. Auf diese Frage gibt es eine ausführliche Erklärung:
Heute habe ich zum ersten Mal konkrete Schritte gefunden, um es zu reproduzieren.
MEIN SZENARIO: Ich habe 4 Commits für master , die ich nun in einen topic Zweig verschieben soll, plus Ich möchte sie neu anordnen. Wenn ich es so mache ...
Erstellen Sie einen neuen Zweig topic , der den aktuellen Zweig verfolgt ( master )
Zurückspulen master zurück:
Ordne die Commits für topic
... dann erscheint auf dem Bildschirm für die interaktive Umbenennung eine ominöse Liste von Commits:
%Vor% Uh-oh ... Ich speichere die Datei und fahre trotzdem fort. Yup, sieht aus wie Git weggeworfen meine Arbeit wieder. topic zeigt jetzt auf dasselbe Commit wie master und origin/master .
Also ich vermute, was für Sie ausgelöst hat, ist:
Upgrade von git
Sie haben so etwas wie meinen zweiten Schritt in Ihrem master Zweig gemacht.
Nach meinem Laienverständnis durchsucht die fork-point -Maschinerie den Reflog und merkt, dass diese Commits aus dem Upstream-Zweig entfernt wurden, und kommt zu dem Schluss, dass Sie Ihre Zweigstelle "auf den neuesten Stand" bringen sollte auch dort entfernt werden.
Die Lösung ist statt:
%Vor%Verwenden Sie eine der folgenden Optionen:
%Vor% Aber ich vermute, ich würde das nicht jedes Mal tun. (Ich meine, wir haben aus einem bestimmten Grund eine Upstream-Zweigstelle eingerichtet, oder?) Damit Sie einfach erkennen, wann diese Katastrophe eintritt, verwenden Sie git reflog und git reset --hard zur Wiederherstellung und dann der obige Befehl.
Trotzdem müssen Sie jetzt vorsichtig sein - ich denke, das ist extrem gefährlich. Ich hatte Zeiten, in denen ich einen großen Zweig reabasiert habe und ein paar Commits von Anfang an lautlos verschwunden waren, und das habe ich seit Tagen nicht bemerkt! Ich bin ziemlich zufrieden damit, git reflog für Disaster Recovery zu verwenden, aber ich bin mir nicht sicher, ob es wirklich alle sind. Ich frage mich, ob Git jetzt zu clever hier ist.
Führen Sie git branch -vv aus, um Upstream-Zweige zu sehen. Es klingt so, als wäre dein Upstream für mystuff nicht das, was du denkst. Vielleicht hatten Sie einen Bearbeitungsunfall und am Ende mehrere [branch "mystuff"] Einträge in Ihrer Konfiguration?
Tags und Links git git-rebase