Warum fortgeschrittene Features wichtig sind
Mit Commits, Branches und Merges kann man schon sehr viel erreichen. Aber in echten Projekten tauchen Situationen auf, in denen man flexibler sein muss:
- Ein Branch ist veraltet und muss „aufgefrischt“ werden.
- Du willst Änderungen sichern, ohne sie sofort zu committen.
- Du brauchst nur einen bestimmten Commit, nicht den ganzen Branch.
- Du willst eine Version offiziell markieren.
Hier kommen die fortgeschrittenen Techniken ins Spiel.
Rebase – eine aufgeräumte Historie
Was ist Rebase?
git rebase verschiebt deine Commits auf einen anderen Branch, als wären sie dort direkt entstanden.
- Vorteil: eine lineare Historie ohne unnötige Merge-Commits.
- Nachteil: Die Commit-IDs ändern sich (weil sie quasi „neu geschrieben“ werden).
Beispiel: Merge vs. Rebase
Mit Merge
A---B---C (main)
\
D---E (feature)
Merge erzeugt:
A---B---C---M (main)
\ /
D---E
Mit Rebase
A---B---C (main)
\
D'---E' (feature)
👉 Sieht sauberer aus, als wären D und E direkt nach C entstanden.
Typischer Einsatz
Wenn du an einem Feature arbeitest, während main schon weitergelaufen ist:
git checkout feature
git rebase main
Vorsicht
- Nie rebasen, wenn der Branch schon öffentlich geteilt wurde.
- Sonst überschneidet sich die Historie mit den Branches anderer Entwickler.
Stash – Änderungen zwischenspeichern
Problem
Du arbeitest an etwas, bist aber noch nicht fertig – und plötzlich musst du auf einen anderen Branch wechseln.
Aber: Deine Änderungen sind nicht committet.
Lösung: git stash
git stash
- Änderungen verschwinden aus dem Arbeitsverzeichnis.
- Git speichert sie im „Stapel“.
Zurückholen:
git stash pop
Mehrere Stashes verwalten
- Liste anzeigen:
git stash list - Bestimmten Stash anwenden:
git stash apply stash@{2} - Löschen:
git stash drop stash@{0}
👉 Super praktisch für Kontextwechsel.
Cherry-Pick – gezielte Commits übernehmen
Was ist Cherry-Pick?
Stell dir vor: Du hast einen Bugfix in Branch hotfix gemacht – und willst genau diesen Commit auch in main.
Anstatt den ganzen Branch zu mergen:
git checkout main
git cherry-pick <commit-id>
👉 Ergebnis: Nur dieser Commit wird übernommen.
Typische Anwendungsfälle
- Bugfix in mehrere Versionen übernehmen.
- Einen vergessenen Commit nachträglich hinzufügen.
Tags – Versionen markieren
Was ist ein Tag?
Ein Tag ist ein fester Zeiger auf einen bestimmten Commit.
- Gut für Releases (z. B.
v1.0,v2.1.3). - Anders als Branches ändern sich Tags nicht mehr.
Tags erstellen
- Einfach:
git tag v1.0 - Mit Nachricht (annotated):
git tag -a v1.0 -m "Version 1.0 Release"
Tags teilen
Standardmäßig werden Tags nicht mitgepusht.
git push origin v1.0
oder alle Tags:
git push origin --tags
Tags nutzen
- Bestimmten Stand auschecken:
git checkout v1.0 - Nützlich für Builds und Deployments.
Logs und Historie im Detail
Standard-Log
git log
zeigt alle Commits ausführlich.
Kurz und knackig
git log --oneline --graph --decorate --all
- oneline → kurze Commit-Messages.
- graph → ASCII-Diagramm der Branches.
- decorate → zeigt Branch- und Tag-Namen.
- all → alle Branches.
Beispielausgabe:
* e3a1b2c (HEAD -> main, tag: v1.0) Release 1.0
* d2c3a4b Fix login bug
| * a1b2c3d (feature) Add signup page
|/
* c4d5e6f Initial commit
Unterschiedliche Versionen vergleichen
- Änderungen seit letztem Commit:
git diff - Unterschiede zwischen zwei Commits:
git diff a1b2c3d d4e5f6g
Wer hat was geändert?
git blame index.html
Zeigt für jede Zeile, von wem sie zuletzt bearbeitet wurde.
Praktische Kombinationen
- Rebase + Interactive
git rebase -i HEAD~3→ erlaubt Commits zusammenzufassen, umzubenennen oder zu löschen. - Stash + Branch
git stash git checkout -b fix-branch git stash pop→ Änderungen schnell in neuen Branch übernehmen. - Cherry-Pick + Tag
→ Hotfix übernehmen und mit neuem Tag als Release markieren.
Best Practices für Fortgeschrittene
- Rebase für private Branches – Saubere Historie, solange du alleine arbeitest.
- Merge für geteilte Branches – Vermeide Historienchaos bei Teamarbeit.
- Tags für Releases – Nie eine Version ohne Tag deployen.
- Stash nur kurz nutzen – besser kleine Commits machen.
- Cherry-Pick sparsam einsetzen – kann unübersichtlich werden, wenn man viele einzelne Commits verteilt.
Schreibe einen Kommentar