Zusammenfassung
Die Fehlermeldung
Ohne vorheriges Festschreiben kann nicht "gequetscht" werden
bedeutet, dass Sie wahrscheinlich versucht haben, "nach unten zu quetschen". Git zerquetscht ein neueres Commit immer in ein älteres Commit oder "aufwärts", wie in der interaktiven Rebase-Aufgabenliste angezeigt, dh in einem Commit in einer vorherigen Zeile. Wenn Sie den Befehl in der ersten Zeile Ihrer Aufgabenliste in ändern, squashwird immer dieser Fehler ausgegeben, da für das erste Commit nichts zum Squash vorhanden ist.
Die Reparatur
Kommen Sie zuerst dorthin zurück, wo Sie angefangen haben
$ git rebase --abort
Sagen Sie, Ihre Geschichte ist
$ git log --pretty=oneline
a931ac7c808e2471b22b5bd20f0cad046b1c5d0d c
b76d157d507e819d7511132bdb5a80dd421d854f b
df239176e1a2ffac927d8b496ea00d5488481db5 a
Das heißt, a war das erste Commit, dann b und schließlich c. Nachdem wir c festgelegt haben, beschließen wir, b und c zusammen zu quetschen:
(Hinweis: Beim Ausführen von git logPipes wird die Ausgabe lessstandardmäßig auf den meisten Plattformen in einen Pager geleitet . Um den Pager zu beenden und zur Eingabeaufforderung zurückzukehren, drücken Sie die qTaste.)
Laufen git rebase --interactive HEAD~2gibt Ihnen einen Editor mit
pick b76d157 b
pick a931ac7 c
# Rebase df23917..a931ac7 onto df23917
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
(Beachten Sie, dass diese Aufgabenliste im Vergleich zur Ausgabe von in umgekehrter Reihenfolge ist git log.)
Ändern bs führt zum Fehler , den Sie gesehen haben, aber wenn Sie stattdessen c in b zerquetschen (neuere begeht in die älteren oder „Quetschen nach oben“) , indem Sie die To - do - Liste zu ändern , umpicksquash
pick b76d157 b
squash a931ac7 c
Wenn Sie Ihren Editor speichern, erhalten Sie einen anderen Editor, dessen Inhalt ist
# This is a combination of 2 commits.
# The first commit's message is:
b
# This is the 2nd commit message:
c
Wenn Sie speichern und beenden, wird der Inhalt der bearbeiteten Datei zur Festschreibungsnachricht des neuen kombinierten Festschreibens:
$ git log --pretty=oneline
18fd73d3ce748f2a58d1b566c03dd9dafe0b6b4f b and c
df239176e1a2ffac927d8b496ea00d5488481db5 a
Hinweis zum Umschreiben des Verlaufs
Interaktive Rebase schreibt den Verlauf neu. Der Versuch, auf eine Fernbedienung zu pushen, die den alten Verlauf enthält, schlägt fehl, da es sich nicht um einen schnellen Vorlauf handelt.
Wenn der Zweig, den Sie neu gegründet haben, ein Thema oder ein Feature-Zweig ist, in dem Sie selbst arbeiten , ist das keine große Sache. Für das Verschieben in ein anderes Repository ist die --forceOption erforderlich. Abhängig von den Berechtigungen des Remote-Repositorys können Sie möglicherweise zuerst den alten Zweig löschen und dann die neu basierte Version übertragen. Beispiele für Befehle, die möglicherweise die Arbeit zerstören, sind nicht Gegenstand dieser Antwort.
Umschreiben von bereits veröffentlichten Geschichte auf einem Zweig , in dem Sie mit anderen Menschen arbeiten , ohne sehr guten Grund , wie ein Passwort oder andere sensible Details Kräfte arbeiten auf Ihre Mitarbeiter undicht und ist unsozial und andere Entwickler ärgern. Der Abschnitt „Wiederherstellen von einer Upstream-Rebase“ in der git rebaseDokumentation wird mit zusätzlichem Schwerpunkt erläutert.
Das Wiederherstellen (oder jede andere Form des Umschreibens) eines Zweigs, auf dem andere basieren, ist eine schlechte Idee: Jeder, der ihm nachgeschaltet ist, muss seinen Verlauf manuell korrigieren. In diesem Abschnitt wird erläutert, wie die Korrektur aus Sicht des Downstreams durchgeführt wird. Die eigentliche Lösung wäre jedoch, zu vermeiden, dass der Upstream überhaupt neu aufgebaut wird. …