Werkzeuge für Profis und Problemlösung

Bislang haben wir das Idealszenario betrachtet: Sie schreiben Code, machen Commits, erstellen einen Pull Request. Doch im echten Leben läuft oft etwas nicht wie geplant: Sie können einen Fehler im Code machen, einen Commit mit einer falschen Nachricht erstellen oder einfach feststellen, dass Sie in die falsche Richtung gegangen sind. In dieser Vorlesung schauen wir uns an, wie man die häufigsten Probleme löst.

1. Rollback – Änderungen vor dem Commit rückgängig machen

Szenario: Sie haben eine Datei geändert, aber gemerkt, dass alle Ihre Anpassungen falsch sind und möchten die Datei schnell in den Zustand zurückversetzen, in dem sie nach dem letzten Commit war.

Verwenden Sie die Funktion Rollback:

1. Öffnen Sie den Tab Commit.
2. Suchen Sie in der Liste die geänderte Datei, die Sie „zurücksetzen“ möchten.
3. Klicken Sie mit der rechten Maustaste darauf und wählen Sie Rollback.

Die IDE warnt Sie, dass die Änderungen verloren gehen. Bestätigen Sie, und die Datei wird sofort auf ihre zuletzt in Git gespeicherte Version zurückgesetzt. Das ist der einfachste und sicherste Weg, lokale Änderungen rückgängig zu machen.

2. Reset – lokale Commits löschen

Szenario: Sie haben einen oder mehrere Commits gemacht, aber noch keinen push ausgeführt. Sie haben erkannt, dass diese Commits fehlerhaft sind, und möchten sie vollständig entfernen, als hätte es sie nie gegeben.

Verwenden Sie die Funktion Reset:

1. Öffnen Sie den Tab Git -> Log, um die Commit-Historie zu sehen.
2. Finden Sie den letzten „guten“ Commit, bei dem Sie landen möchten (den, der vor den fehlerhaften lag).
3. Klicken Sie mit der rechten Maustaste darauf und wählen Sie Reset Current Branch to Here....

Im geöffneten Fenster können Sie den Reset-Modus wählen. Die radikalste Option ist Hard.

Achtung! Der Modus Hard löscht unwiderruflich alle Commits nach dem ausgewählten sowie alle Änderungen im Code, die in diesen Commits enthalten waren. Verwenden Sie ihn mit großer Vorsicht und nur für Commits, die noch niemand gesehen hat (also die nicht auf GitHub gepusht wurden).

3. Was tun nach dem Push?

Szenario: Sie haben einen push gemacht und erst danach einen Fehler darin bemerkt.

Sobald ein Commit auf dem Remote-Server ist, wird er Teil der gemeinsamen Projekt-Historie. Der Versuch, diese Historie umzuschreiben, kann enorme Probleme für Ihre Kolleginnen und Kollegen verursachen. Stellen Sie sich vor, sie haben Ihre Änderungen bereits heruntergeladen und ihre Arbeit darauf aufgebaut.

Die richtige und sichere Lösung:

Erstellen Sie einfach einen neuen Commit, der den Fehler behebt, und senden Sie ihn. Das ist völlig normal. So bleibt die Historie ehrlich und für alle nachvollziehbar.

4. Ein Blick in die Vergangenheit: fortgeschrittene Arbeit mit dem Log

Wir kennen bereits den Tab Git -> Log, doch das ist nicht nur eine Liste von Commits, sondern ein mächtiges Werkzeug für Nachforschungen.

• Commit-Hash: Sie haben im Log sicher eine Zeichenfolge aus Buchstaben und Ziffern bemerkt, zum Beispiel a1b2c3d. Dieser Hash ist eindeutig und erlaubt es, auf jeden Punkt der Projekt-Historie exakt zu verweisen. Sie werden ihn selten manuell verwenden müssen, aber es ist wichtig zu wissen, dass dies der eindeutige Bezeichner jedes „Schnappschusses“ Ihres Codes ist.
• Sie können die Historie nach Branch, Autor, Datum oder sogar nach einem Wort in der Commit-Nachricht filtern. Das hilft, schnell herauszufinden, wer wann an einem bestimmten Teil der Funktionalität gearbeitet hat.
• Möchten Sie den Commit finden, in dem eine bestimmte Codezeile hinzugefügt oder gelöscht wurde? Im Fenster Log gibt es ein Suchfeld, das nicht nur in Nachrichten, sondern auch im Inhalt der Änderungen selbst sucht.
• Klicken Sie im Code-Editor mit der rechten Maustaste am Rand und wählen Sie Annotate with Git Blame. Die IDE zeigt neben jeder Zeile, wer sie in welchem Commit zuletzt geändert hat. Das ist unglaublich hilfreich, um zu verstehen, warum der Code genau so geschrieben ist.

5. Gefahrenzone: Force Push

Wir haben festgestellt, dass das Ändern bereits gesendeter Commits eine schlechte Idee ist. Aber was, wenn Sie dennoch Ihre lokale Historie geändert haben (z. B. mit Reset) und diese nun von der Historie auf dem Server abweicht? Beim Versuch, einen normalen push auszuführen, gibt Git einen Fehler aus, um die gemeinsame Historie vor dem Überschreiben zu schützen.

Für solche Fälle gibt es die Option – force push (erzwungenes Pushen). Dieser Befehl sagt dem Server: „Vergiss alles, was du hattest. Meine lokale Version der Historie ist die einzig richtige. Ersetze deine Historie durch meine.“

ACHTUNG! In 99 % der Fälle ist die Verwendung von force push in Teamprojekten eine Katastrophe. Das kann unwiderruflich Commits löschen, die Ihre Kolleginnen und Kollegen bereits heruntergeladen haben und auf deren Basis sie arbeiten. Das ist so, als würden Sie Seiten aus einem gemeinsamen Bibliotheksbuch herausreißen und Ihre eigenen einkleben.

Wann auf keinen Fall force push verwenden:

• Auf beliebige gemeinsame Branches: main, develop, master. Niemals.
• Auf jeden Branch, an dem außer Ihnen noch jemand arbeitet.

Das einzige zulässige Szenario:

Sie arbeiten in Ihrem eigenen persönlichen Feature-Branch, den noch niemand gesehen oder verwendet hat. Sie haben ein paar „schmutzige“ Commits gemacht, sie auf den Server gesendet und dann beschlossen, sie mit Reset „aufzuräumen“. In diesem Fall können Sie ein force push ausführen, um Ihren Branch auf dem Server zu aktualisieren, bevor Sie einen Pull Request erstellen.

In der IDE ist diese Option normalerweise hinter der Schaltfläche Push versteckt. Die IDE-Entwickler haben das bewusst so gemacht, damit Sie sie nicht versehentlich drücken.

Wenn Sie sich nicht zu 100 % sicher sind, was Sie tun, verwenden Sie niemals force push. Es ist sicherer, einen neuen Commit mit Korrekturen zu erstellen.

6. Projekt aktualisieren

Klicken Sie immer auf Update Project im Branch main, bevor Sie mit einer neuen Aufgabe beginnen. Das bewahrt Sie vor vielen zukünftigen Merge-Konflikten und stellt sicher, dass Sie mit der aktuellsten Version des Codes starten.