Teil 5 – Fehler beheben und Best Practices

Warum Fehler unvermeidbar sind

Selbst erfahrene Entwickler machen in Git Fehler:

• Falsche Datei committet.
• Branch gelöscht.
• Änderungen überschrieben.
• Große Dateien versehentlich hochgeladen.

Die gute Nachricht: Git ist wie eine Zeitmaschine – fast alles lässt sich wiederherstellen. In diesem Teil lernst du die wichtigsten Rettungsanker und Strategien.

---

Typische Fehler und ihre Lösungen

1. Falsche Dateien committet

Du hast versehentlich secret.txt oder eine temporäre Datei committed.

Lösung: Commit rückgängig machen (aber Änderungen behalten)

git reset --soft HEAD~1

• Entfernt den letzten Commit, Änderungen bleiben im Arbeitsverzeichnis.

Lösung: Commit rückgängig machen (und Änderungen verwerfen)

git reset --hard HEAD~1

⚠️ Vorsicht: Änderungen sind weg.

---

2. Datei aus der Historie löschen

Wenn sensible Daten (Passwörter, Keys) ins Repo gekommen sind, reicht ein reset nicht – die Datei bleibt in der Historie.

Lösung: git filter-repo (moderner Ersatz für filter-branch)

git filter-repo --path secret.txt --invert-paths

Danach Force-Push:

git push --force

⚠️ Alle müssen ihr Repo neu klonen, da die Historie geändert wurde.

---

3. Branch gelöscht

Du hast git branch -d feature gemacht, aber brauchst ihn zurück.

Lösung: Überprüfen, wo er war

git reflog

• Zeigt alle Bewegungen von HEAD.
• Dort findest du den letzten Commit des Branches.

Branch neu erstellen:

git checkout -b feature <commit-id>

---

4. Falscher Branch

Du hast auf main entwickelt, statt im Feature-Branch.

Lösung: Änderungen verschieben

1. Neuen Branch erstellen:

git checkout -b feature

2. Auf main zurückspringen und Änderungen zurücksetzen:

git checkout main
git reset --hard origin/main

👉 Jetzt sind die Änderungen im richtigen Branch.

---

5. Push rückgängig machen

Du hast versehentlich etwas gepusht.

Lösung: Force-Push

git reset --hard HEAD~1
git push --force

⚠️ Achtung: Das überschreibt den Remote-Branch – nur nutzen, wenn du alleine an dem Branch arbeitest.

---

6. Merge-Konflikte

Du willst mergen, Git meckert:

<<<<<<< HEAD
<h1>Hallo Welt</h1>
=======
<h1>Login-Seite</h1>
>>>>>>> feature-login

Lösung:

• Konfliktmarker entfernen.
• Manuell entscheiden, was bleibt.
• Datei speichern →

git add index.html
git commit

---

7. Änderungen überschrieben (Reset zu früh gemacht)

Keine Panik – Git löscht fast nichts sofort.

Lösung: reflog

git reflog

• Findet auch verlorene Commits.
• Dann zurücksetzen:

git checkout <commit-id>

---

Git Reset, Revert und Restore – Unterschiede

• Reset → springt an eine alte Stelle, kann Historie ändern.
• Revert → erstellt einen neuen Commit, der Änderungen rückgängig macht. git revert <commit-id> → sicherer für gemeinsame Branches.
• Restore → stellt bestimmte Dateien wieder her. git restore index.html

👉 Faustregel:

• Allein? → reset möglich.
• Im Team? → lieber revert.

---

Best Practices für sauberes Arbeiten

1. Kleine, sinnvolle Commits

• Jeder Commit sollte eine abgeschlossene Änderung darstellen.
• Nicht: „Alles geändert“.
• Besser: „Login-Formular hinzugefügt“, „Validierung ergänzt“.

---

2. Commit-Messages mit Format

Viele Teams nutzen Konventionen wie Conventional Commits:

feat: Login-Formular hinzugefügt
fix: Fehler bei Passwort-Hashing behoben
docs: README aktualisiert

👉 Vorteil: Automatisierte Changelogs möglich.

---

3. Branch-Namen klar wählen

• feature/login-form
• bugfix/password-reset
• release/2.0

So weiß jeder sofort, wofür der Branch da ist.

---

4. Nie direkt auf main arbeiten

• main sollte immer stabil sein.
• Änderungen nur über Feature-Branches + Pull Requests.

---

5. Regelmäßig pullen

• Halte deinen Branch aktuell.
• Verhindert große Merge-Konflikte.

---

6. .gitignore nutzen

• Temporäre Dateien, Logs, Build-Outputs ausschließen.
• Beispiel .gitignore:

node_modules/
*.log
.env

---

7. Backups durch Remotes

• Push regelmäßig zu GitHub/GitLab.
• Dein Laptop kann kaputtgehen – das Remote ist die Rettung.

---

8. Code Reviews

• Pull Requests nutzen.
• Änderungen gemeinsam prüfen.
• Erhöht Codequalität und Sicherheit.

---

9. Releases mit Tags

• Wichtige Versionen immer taggen.
• Nie ohne Tag deployen.

---

Praktisches Szenario: Typischer Fehler im Team

1. Entwickler A und B arbeiten gleichzeitig.
2. A pusht Änderungen.
3. B hat lokal auch Änderungen, macht git push → Fehler: ! [rejected] main -> main (non-fast-forward)
4. B muss zuerst git pull.
5. Git versucht zu mergen → Konflikt.
6. B löst Konflikt, committet, pusht.

👉 Ergebnis: Beide Änderungen sind integriert, nichts ging verloren.