Werkzeuge des Professionals und Problemlösung

Bisher haben wir das ideale Szenario betrachtet: du schreibst Code, machst Commits, erstellst einen Pull Request. In der Realität läuft aber oft etwas schief: du kannst einen Fehler im Code machen, einen Commit mit falscher Nachricht erstellen oder einfach merken, dass du in die falsche Richtung gegangen bist. In dieser Vorlesung gehen wir durch, wie man die häufigsten Probleme löst.

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

Szenario: du hast eine Datei geändert, merkst aber, dass alle deine Änderungen falsch sind und willst die Datei schnell in den Zustand zurücksetzen, in dem sie nach dem letzten Commit war.

Nutze die Funktion Rollback:

1. Öffne den Tab Commit.
2. Finde in der Liste die geänderte Datei, die du "zurückrollen" möchtest.
3. Klick mit der rechten Maustaste darauf und wähle Rollback.

Die IDE wird dich warnen, dass die Änderungen verloren gehen. Bestätige das, und die Datei wird sofort auf die 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 entfernen

Szenario: du hast einen oder mehrere Commits gemacht, aber noch keinen push. Du merkst, dass diese Commits fehlerhaft sind und willst sie komplett entfernen, als wären sie nie geschehen.

Nutze die Funktion Reset:

1. Öffne den Tab Git -> Log, um die Commit-Historie zu sehen.
2. Finde den letzten "guten" Commit, auf dem du landen möchtest (denjenigen, der vor den fehlerhaften Commits kam).
3. Klick mit der rechten Maustaste darauf und wähle Reset Current Branch to Here....

In dem sich öffnenden Fenster wirst du aufgefordert, einen Reset-Modus zu wählen. Der radikalste ist Hard.

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

3. Was tun nach dem Push?

Szenario: du hast push ausgeführt und erst danach einen Fehler bemerkt.

Sobald ein Commit auf den Remote-Server gelangt ist, wird er Teil der gemeinsamen Projekthistorie. Der Versuch, diese Historie umzuschreiben, kann für deine Kolleg:innen große Probleme verursachen. Stell dir vor, sie haben deine Änderungen bereits heruntergeladen und bauen darauf auf.

Die richtige und sichere Lösung:

Mach einfach einen neuen Commit, der den Fehler behebt, und pushe diesen. Das ist absolut normale Praxis. So bleibt die Historie ehrlich und verständlich für alle.

4. In die Vergangenheit schauen: fortgeschrittene Arbeit mit dem Log

Wir kennen bereits den Tab Git -> Log, aber das ist nicht nur eine Liste von Commits, sondern ein mächtiges Tool zur Untersuchung.

• Commit-Hash: du hast sicher die Zeile aus Buchstaben und Zahlen im Log bemerkt, z. B. a1b2c3d. Dieser Hash ist einzigartig und erlaubt es, genau auf einen Punkt in der Projektgeschichte zu verweisen. Du musst ihn selten manuell verwenden, aber es ist wichtig zu wissen, dass das der eindeutige Identifikator jedes "Snapshots" deines Codes ist.
• Du kannst die Historie nach Branch, Autor, Datum oder sogar nach einem Wort in der Commit-Nachricht filtern. Das hilft, schnell zu finden, wer wann an einem bestimmten Teil des Features gearbeitet hat.
• Willst du den Commit finden, in dem eine bestimmte Codezeile hinzugefügt oder entfernt wurde? Im Log-Fenster gibt es ein Suchfeld, das nicht nur nach Nachrichten, sondern auch nach dem Inhalt der Änderungen sucht.
• Klick mit der rechten Maustaste in die Ränder des Code-Editors und wähle Annotate with Git Blame. Die IDE zeigt neben jeder Zeile, wer und in welchem Commit sie zuletzt geändert wurde. Das ist unglaublich nützlich, um zu verstehen, warum der Code so geschrieben wurde.

5. Gefährliche Zone: Force Push

Also: wir haben festgestellt, dass das Ändern bereits gepushter Commits eine schlechte Idee ist. Aber was, wenn du trotzdem deine lokale Historie verändert hast (z. B. mit Reset) und sie jetzt von der Server-Historie abweicht? Beim Versuch, normal zu pushen, wird Git einen Fehler melden, um die gemeinsame Historie vor Überschreibung zu schützen.

Für solche Fälle gibt es die Option — force push (erzwungenes Pushen). Dieser Befehl sagt dem Server: "Vergiss, was du hattest. Meine lokale Historie ist die wahre. Ersetze deine Historie mit meiner".

ACHTUNG! In 99% der Fälle ist die Nutzung von force push in Teamprojekten eine Katastrophe. Das kann unwiderruflich Commits löschen, die deine Kolleg:innen bereits heruntergeladen haben und auf denen sie arbeiten. Es ist so, als würdest du Seiten aus einem gemeinsamen Bibliotheksbuch herausreißen und deine eigenen einkleben.

Wann du auf keinen Fall force push verwenden solltest:

• Auf irgendwelche gemeinsamen Branches: main, develop, master. Niemals.
• Auf jeden Branch, an dem außer dir noch jemand arbeitet.

Das einzig akzeptable Szenario:

Du arbeitest in deiner persönlichen Feature-Branch, die noch niemand gesehen oder genutzt hat. Du hast mehrere "dirty" Commits gemacht, sie auf den Server gepusht und später entschieden, sie mit Reset aufzuräumen. In diesem Fall kannst du force push machen, um deinen Branch auf dem Server vor dem Erstellen eines Pull Requests zu aktualisieren.

In der IDE ist diese Option normalerweise hinter der Schaltfläche Push versteckt. Die Entwickler der IDE haben das absichtlich so gemacht, damit du nicht versehentlich darauf klickst.

Wenn du dir nicht zu 100% sicher bist, was du tust — benutze niemals force push. Es ist sicherer, einen neuen Commit mit den Korrekturen zu erstellen.

6. Projekt aktualisieren

Drücke immer Update Project auf dem Branch main, bevor du mit einer neuen Aufgabe beginnst. Das schützt dich vor vielen zukünftigen Merge-Konflikten und stellt sicher, dass du mit der aktuellsten Codebasis startest.