So prüfen Sie, ob ein Git-Branch lokal gelöscht wurde

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob ein Git-Branch lokal gelöscht wurde. Wir beginnen damit, die Abwesenheit eines bestimmten Branches mit git branch zu überprüfen, um einen sauberen Ausgangszustand sicherzustellen. Anschließend werden wir uns das git reflog-Kommando ansehen, ein leistungsstarkes Werkzeug, das Updates von Referenzen in Ihrem lokalen Repository aufzeichnet, einschließlich Branch-Löschungen, und es Ihnen ermöglicht, die Änderungshistorie einzusehen. Abschließend werden wir diese Methoden testen, indem wir mit einem kürzlich gelöschten Branch arbeiten, um zu bestätigen, wie Sie effektiv den Status seiner lokalen Löschung prüfen können.

Skills Graph

Ausführen von git branch zur Überprüfung der Abwesenheit

In diesem Schritt werden wir überprüfen, dass ein bestimmter Branch, den wir später löschen werden, derzeit nicht in unserem Git-Repository vorhanden ist. Dies ist eine gute Praxis, um sicherzustellen, dass wir von einem sauberen Zustand ausgehen, bevor wir Operationen wie das Löschen von Branches ausführen.

Zunächst navigieren Sie in das Projektverzeichnis, falls Sie nicht bereits dort sind. Denken Sie daran, dass unser Projekt sich unter ~/project/my-time-machine befindet.

cd ~/project/my-time-machine

Nun listen wir die vorhandenen Branches in unserem Repository mit dem git branch-Befehl auf. Standardmäßig zeigt dieser Befehl die lokalen Branches an.

git branch

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

* master

Diese Ausgabe zeigt an, dass derzeit nur der master-Branch existiert und dass es sich um den aktiven Branch handelt (angezeigt durch das Sternchen *).

Für das Zweck dieses Labs werden wir mit einem Branch namens feature/new-feature arbeiten. Lassen Sie uns bestätigen, dass dieser Branch noch nicht existiert, indem wir git branch erneut ausführen. Da wir es gerade ausgeführt haben und nur master gesehen haben, wissen wir bereits, dass er nicht vorhanden ist, aber das erneute Ausführen des Befehls verstärkt das Konzept des Prüfens des Branch-Status.

git branch

Die Ausgabe sollte immer noch nur den master-Branch anzeigen:

* master

Dies bestätigt, dass der feature/new-feature-Branch derzeit nicht in unserem Repository vorhanden ist. Dies ist der Zustand, den wir erwarten, bevor wir in den folgenden Schritten diesen Branch erstellen und dann löschen. Das Verständnis, wie man den Status seiner Branches prüft, ist grundlegend für die effektive Verwaltung der Projektgeschichte.

Prüfen des git reflog auf Löschungen

In diesem Schritt werden wir uns das git reflog-Kommando ansehen, ein leistungsstarkes Werkzeug zum Wiederherstellen verlorener Commits oder Branches. Das reflog (Referenzprotokoll) protokolliert Updates an den Endpunkten von Branches und anderen Referenzen im lokalen Repository. Das bedeutet, dass es fast jede Änderung protokolliert, die Sie in Ihrem Repository vornehmen, einschließlich Commits, Merges, Rebases und sogar Branch-Löschungen.

Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project/my-time-machine

Nun erstellen wir einen neuen Branch, den wir später löschen werden. So haben wir etwas, wonach wir im reflog suchen können.

git branch feature/new-feature

Dieser Befehl erstellt einen neuen Branch namens feature/new-feature, der auf den aktuellen Commit zeigt. Lassen Sie uns überprüfen, ob er existiert:

git branch

Sie sollten jetzt beide Branches sehen:

* master
  feature/new-feature

Nun löschen wir den feature/new-feature-Branch mit der -d-Option, die für ein "sicheres" Löschen steht (es verhindert das Löschen, wenn der Branch ungemergte Änderungen hat).

git branch -d feature/new-feature

Sie sollten eine Ausgabe sehen, die die Löschung bestätigt:

Deleted branch feature/new-feature (was <commit-id>).

Ersetzen Sie <commit-id> durch die tatsächliche Commit-ID, die in Ihrem Terminal angezeigt wird.

Nun prüfen wir das reflog, um zu sehen, ob die Löschung protokolliert wurde.

git reflog

Die Ausgabe zeigt eine Historie der Aktionen. Sie sollten einen Eintrag in Bezug auf die Branch-Löschung sehen, ähnlich wie dieser (die genaue Ausgabe kann variieren):

<commit-id> HEAD@{0}: branch: deleted feature/new-feature
<commit-id> HEAD@{1}: branch: Created from <another-commit-id>
... (andere reflog-Einträge)

Der reflog-Eintrag HEAD@{0}: branch: deleted feature/new-feature zeigt an, dass der feature/new-feature-Branch gelöscht wurde. HEAD@{0} bezieht sich auf die neueste Aktion. Dies zeigt, dass auch wenn der Branch aus git branch verschwunden ist, seine Löschung im reflog protokolliert wird, was seine potenzielle Wiederherstellung ermöglicht.

Das Verständnis von git reflog ist von entscheidender Bedeutung, da es wie ein Sicherheitsnetz fungiert. Wenn Sie versehentlich einen Branch löschen oder Commits aufgrund eines Rebases oder einer anderen Operation verlieren, kann das reflog Ihnen helfen, die Commit-ID zu finden, die Sie benötigen, um Ihre Arbeit wiederherzustellen.

Test mit kürzlich gelöschtem Branch

In diesem Schritt werden wir zeigen, wie man mithilfe der Informationen aus dem git reflog einen kürzlich gelöschten Branch möglicherweise wiederherstellen kann. Obwohl wir in diesem speziellen Lab den Branch nicht vollständig wiederherstellen werden (da er keine einzigartigen Commits hatte), werden wir das Kommando für die Wiederherstellung üben.

Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project/my-time-machine

Denken Sie sich aus dem vorherigen Schritt zurück, dass wir den feature/new-feature-Branch gelöscht haben. Lassen Sie uns bestätigen, dass er immer noch weg ist:

git branch

Die Ausgabe sollte immer noch nur den master-Branch anzeigen:

* master

Nun schauen wir uns erneut das reflog an, um den Eintrag für den gelöschten Branch zu finden.

git reflog

Suchen Sie die Zeile, die branch: deleted feature/new-feature sagt. Notieren Sie sich die Commit-ID, die mit diesem Eintrag verknüpft ist. Es wird so etwas wie <commit-id> HEAD@{0}: branch: deleted feature/new-feature aussehen.

Um einen gelöschten Branch wiederherzustellen, würden Sie normalerweise das git branch <branch-name> <commit-id>-Kommando verwenden, wobei <branch-name> der Name ist, den Sie dem wiederhergestellten Branch geben möchten, und <commit-id> die Commit-ID aus dem reflog ist, auf die der Branch zuletzt gezeigt hat.

In unserem Fall wurde der feature/new-feature-Branch erstellt und sofort gelöscht, ohne dass es neue Commits darauf gab. Daher wird seine Commit-ID im reflog die gleiche wie die Spitze des master-Branches sein. Das Wiederherstellen würde im Wesentlichen nur den Branch neu erstellen, der auf den gleichen Commit wie master zeigt.

Lassen Sie uns das Wiederherstellungs-Kommando simulieren, indem wir die Commit-ID verwenden, die Sie im reflog für den gelöschten Branch gefunden haben. Ersetzen Sie <commit-id> durch die tatsächliche ID aus Ihrer reflog-Ausgabe.

git branch recovered-feature <commit-id>

Dieser Befehl erstellt einen neuen Branch namens recovered-feature, der auf die Commit-ID zeigt, auf die feature/new-feature vor der Löschung gezeigt hat.

Nun prüfen wir unsere Branches erneut:

git branch

Sie sollten jetzt den recovered-feature-Branch in der Liste sehen:

* master
  recovered-feature

Dies zeigt, wie Sie das git reflog verwenden können, um die Commit-ID eines verlorenen Branches zu finden und dann git branch verwenden, um ihn neu zu erstellen. Dies ist eine leistungsstarke Technik, um von versehentlichen Löschungen oder anderen geschichtsverändernden Operationen wiederherzustellen.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man mithilfe des git branch-Kommandos die Abwesenheit eines lokalen Git-Branches überprüft. Wir haben bestätigt, dass es wichtig ist, den aktuellen Branch-Status zu prüfen, bevor man einen Branch erstellt und löscht, um einen sauberen Ausgangspunkt zu gewährleisten.

Wir haben auch begonnen, das git reflog-Kommando zu erkunden und verstanden, welche Rolle es bei der Verfolgung von Änderungen an Referenzen im lokalen Repository spielt, einschließlich Branch-Löschungen. Dies ist von entscheidender Bedeutung für die potenzielle Wiederherstellung verlorener Arbeit.