Wie behebt man einen “abgelösten HEAD” in einem Git-Repository?

0
1028

Eine der regelmäßigen Fehlermeldungen, auf die Sie wahrscheinlich stoßen werden Git ist die Warnung, dass “Sie befinden sich im ‘getrennten HEAD’ Staat.” Sie sind vielleicht versehentlich darauf gestolpert, aber keine Sorge, es ist ein normales Problem und kann leicht behoben werden, sobald Sie verstehen, was es bedeutet.

Was ist Git HEAD?

“HEAD” ist einfach ein Alias ​​für Ihren aktuellen Arbeits-Commit, ähnlich wie Ihr aktuelles Verzeichnis auf einer Befehlszeile. Egal in welchem ​​Zustand sich Ihr Git-Repository befindet, HEAD zeigt immer auf etwas und neue Commits werden vor dem HEAD angehängt.

Normalerweise verweist HEAD nicht direkt auf einen einzelnen Commit. Es zeigt stattdessen auf einen Branch und verweist indirekt auf den letzten Commit in diesem Branch. Wann immer Sie “zur Kasse” einen neuen Branch, Git schaltet den HEAD auf diesen Branch um. Auf diese Weise können Sie neue Commits erstellen, die an das Ende dieses Zweigs angehängt werden.

Sie können sich jedoch auch einzelne Commits ansehen. Was wäre, wenn Sie das Repository zu einem bestimmten Zeitpunkt untersuchen wollten? Das ist einer der großen Vorteile von Git, aber es stellt ein kleines Problem mit der Struktur von Git dar. Da neue Commits einen Branch nicht aktualisieren, werden alle Commits, die Sie machen, nachdem Sie den HEAD entfernt haben, von allen Branch-Referenzen getrennt, daher wird “getrennter HEAD”

Dies kann tatsächlich ziemlich nützlich sein. Angenommen, Sie haben den HEAD ein paar Commits nach hinten verschoben und dann einige experimentelle Updates vorgenommen. Sie erstellen im Grunde einen neuen Branch, der später wieder mit dem Master zusammengeführt werden könnte.

Werbung

Sie müssen es offiziell in das Git-Repository integrieren Wenn Sie sich entscheiden, die Änderungen beizubehalten, aber als Werkzeug für die Durchführung von Back-in-Time-Änderungen ist ein abgetrennter HEAD nicht so beängstigend, wie es sich anhört.

Wenn Sie durch einen Unfall hierher gekommen sind

Es ist sehr einfach, versehentlich hier zu landen und sich über die Fehlermeldung zu wundern, über die sich Git beschwert, obwohl nichts falsch gemacht wurde. Zum Glück ist es unglaublich einfach zu beheben:

Wenn Sie gerade einen Commit ausgecheckt haben und das Repository sonst nicht angerührt haben (es wurden keine neuen Commits gemacht), können Sie die . einfach verschieben Gehen Sie mit git checkout dorthin zurück, wo es hingehört:

git checkout master

Dies ist im Grunde wie das Ausführen von cd unter Linux, außer dass Git zwischengespeicherte Commits und Änderungen immer noch mit dem alten HEAD verknüpft. Sie möchten also nicht zur Kasse gehen, wenn Commits oder Änderungen hängen bleiben würden.

Wenn Sie einige Änderungen vorgenommen haben und diese einfach wegwerfen möchten, können Sie einen Hard-Reset auf den Master zurücksetzen:

git reset –hard origin/master git clean -d –force

Wenn Sie möchten Wenn Sie Ihre Commits jedoch speichern, müssen Sie sie offiziell wieder in die Timeline von Git einfügen.

Wenn Sie Ihre Änderungen speichern möchten

Das erste, was Sie tun sollten, wenn Sie die Änderungen behalten möchten, die Sie in einem abgetrennten HEAD-Zustand vorgenommen haben, ist, einen neuen Zweig zu erstellen. Dies liegt daran, dass der Garbage Collector von Git losgelöste Commits automatisch bereinigt, sodass Sie nie den Überblick verlieren möchten.

git branch dependent-branch Werbung

Dann kann diesen Branch auschecken, um den HEAD so zu verschieben, dass er nicht mehr getrennt ist und stattdessen auf diesen offiziellen neuen Branch zeigt:

git checkout dependent-branch

Sobald die Änderungen aufgezeichnet wurden, haben Sie eine von zwei Optionen. Dieser neue Branch ist im Grunde ein gewöhnlicher Feature-Branch, sodass Sie entweder git merge oder git rebase verwenden können.

Das Zusammenführen ist unkompliziert. checkout master, und führe den abgetrennten Branch zusammen:

git checkout master git merge dependent-branch

Dies funktioniert gut, wenn du in einen Branch integrierst, der eine Genehmigung benötigt, wie es bei Pull-Requests und Code der Fall ist Bewertungen. Möglicherweise müssen Sie den Genehmigungsprozess Ihres Teams durchlaufen, anstatt diese Befehle selbst auszuführen.

Wenn Sie Zugriff haben, z. B. wenn Sie wieder in einen Feature-Branch zusammenführen, an dem Sie gerade arbeiten, ist es eine bessere Methode, die abgetrennten Commits auszuwählen. Beim Rosinenpicken wird im Grunde genommen ein Commit kopiert und in einen anderen Branch eingefügt. Es wird normalerweise verwendet, um bestimmte Commits aus einem Feature-Branch herauszuziehen, bevor das Ganze fertig ist, aber in diesem Fall kann das Rosinenpicken den abgetrennten Branch ohne Merge in Einklang bringen.

Werbung

In diesem Beispiel wird das obige Commit getrennt. Anstatt es zusammenzuführen, wird es ausgewählt und in den Feature-Zweig verschoben. Dadurch werden der HEAD- und der Feature-Zweig so verschoben, dass er ohne Zusammenführung auf den neuesten Commit verweist. Dann kann der ursprüngliche abgetrennte Commit verworfen werden.

Zuerst müssen Sie den abgetrennten Zweig erstellen und dann den Feature-Zweig auschecken, um den HEAD dorthin zu verschieben:

git branch dependent -branch git checkout-Funktion

Führen Sie dann Git log aus, um eine Liste der Commits zu erhalten:

git log –pretty=format:”%h %s” –graph

Dann können Sie einen Commit anhand seiner ID auswählen:

git Cherry -pick 1da76d3

Sobald Sie bestätigt haben, dass die ausgewählten Commits richtig angewendet werden, können Sie den abgetrennten Branch löschen, da die Commits kopiert wurden und nicht mehr verwendet werden.

git branch -D getrennter Zweig

Rebasing statt Zusammenführen

Sie könnten auch ein Rebase durchführen. Rebases unterscheiden sich von Merges darin, dass sie den Branch-Verlauf neu schreiben, die abgetrennten Commits anheben und an den Anfang des Branch verschieben.

Das Problem dabei ist jedoch, dass immer noch zwei Branches übrig bleiben und Sie die Funktion und den abgetrennten Zweig noch zusammenführen müssen. Sie mit einem Merge-Commit in jedem Fall verlassen. Es hinterlässt jedoch im Repository einen lineareren Git-Verlauf, der dem Ausführen von git merge vorzuziehen ist, wenn Sie dazu berechtigt sind.