164 lines
4.8 KiB
Markdown
164 lines
4.8 KiB
Markdown
# 🚀 Git Cheat Sheet: Branches, Merge, Rebase & VS Code
|
||
|
||
## 🌳 Branches (Zweige)
|
||
* **`main`** → Stabiler Stand, Production-ready (Deployment).
|
||
* **`dev`** → Aktive Entwicklung, Sammelbecken für Features.
|
||
|
||
---
|
||
|
||
## 🛠 Zusammenführen von Änderungen
|
||
|
||
### Git Merge
|
||
Führt zwei Zweige zusammen. Git sucht den letzten gemeinsamen Basispunkt und erstellt einen neuen **Merge-Commit**.
|
||
|
||
```bash
|
||
git checkout dev
|
||
git merge main
|
||
```
|
||
|
||
| Details | |
|
||
|-----------|--------|
|
||
| Wann? | In Team-Branches, bei bereits gepushten Branches, wenn Stabilität wichtiger als eine saubere History ist. |
|
||
| Vorteile | Sicher, einfach nachvollziehbar, schreibt die History nicht um. |
|
||
| Nachteile | Die History kann bei vielen Merges unübersichtlich ("Spaghetti-Graph") werden. |
|
||
|
||
### Git Rebase
|
||
Setzt deine Commits neu auf die Spitze eines anderen Branches. Die Commit-IDs werden dabei neu geschrieben.
|
||
|
||
```bash
|
||
git stash # (optional) Änderungen parken.
|
||
git checkout dev
|
||
git fetch origin
|
||
git rebase origin/main
|
||
git stash pop # (optional) Änderungen zurückholen.
|
||
```
|
||
|
||
| Details | |
|
||
|-----------|--------|
|
||
| Wann? | In lokalen Feature-Branches (bevor sie geteilt werden), um die History sauber zu halten. |
|
||
| Vorteile | Erzeugt eine perfekt lineare, leicht lesbare History. |
|
||
| Nachteile | ⚠️ Gefährlich auf geteilten/öffentlichen Branches. Konflikte müssen ggf. für jeden einzelnen Commit gelöst werden. |
|
||
|
||
---
|
||
|
||
## **Git: dev zurücksetzen & „main ist Chef“**
|
||
|
||
Problem
|
||
|
||
Beim Arbeiten mit Git passiert oft Folgendes:
|
||
|
||
- `dev` hat Commits, die nicht in `main` sind
|
||
- diese Commits brauche ich nicht mehr
|
||
- beim `git rebase origin/main` will Git trotzdem mergen oder Konflikte lösen
|
||
|
||
⚠️ Wichtiges Missverständnis:
|
||
|
||
Das sind keine lokalen Änderungen, sondern Commits, die auf `dev` existieren.
|
||
|
||
`git reset --hard origin/dev` entfernt nur lokale, nicht gepushte Commits,
|
||
aber nicht Commits, die bereits auf `origin/dev` liegen.
|
||
|
||
Praktische Befehle & sichere Vorgehensweise
|
||
|
||
- Prüfen — welche Commits würden entfernt werden:
|
||
|
||
```bash
|
||
git fetch origin
|
||
git log --oneline origin/main..origin/dev
|
||
```
|
||
|
||
- Optional: Backup des aktuellen `origin/dev`, falls etwas schiefgeht:
|
||
|
||
```bash
|
||
git fetch origin
|
||
git branch backup/dev origin/dev
|
||
```
|
||
|
||
- Sicheres Zurücksetzen von `dev` auf `main` (lokal + remote):
|
||
|
||
```bash
|
||
git checkout dev
|
||
git fetch origin
|
||
git reset --hard origin/main
|
||
git push --force-with-lease origin dev
|
||
```
|
||
|
||
- Alternative (ohne lokalen Checkout): Push von `main` direkt nach `dev`:
|
||
|
||
```bash
|
||
git fetch origin
|
||
git push --force-with-lease origin origin/main:refs/heads/dev
|
||
```
|
||
|
||
- Warnung: Diese Aktionen schreiben die Remote‑History um. Koordiniere dich mit
|
||
dem Team bevor du ein Force‑Push ausführst. Verwende `--force-with-lease`
|
||
anstelle von `--force` für etwas mehr Sicherheit.
|
||
|
||
|
||
## 📦 Temporäres Speichern & Spezialbefehle
|
||
|
||
### Stash (Das "Regal")
|
||
Speichert uncommitted Changes temporär, um das Arbeitsverzeichnis sauber zu machen, ohne zu committen.
|
||
|
||
```bash
|
||
git stash # Änderungen "parken".
|
||
git stash pop # Änderungen zurückholen und Stash leeren.
|
||
```
|
||
|
||
**Wann?** Wenn du schnell den Branch wechseln musst, aber deine Arbeit noch nicht fertig ist.
|
||
|
||
### Cherry-pick
|
||
Kopiert einen ganz gezielten Commit von einem Branch in deinen aktuellen.
|
||
|
||
```bash
|
||
git cherry-pick <commit-hash>
|
||
```
|
||
|
||
**Wann?** Wenn ein Bugfix auf dem falschen Branch gelandet ist oder du nur eine einzige Funktion aus einem Feature-Branch brauchst.
|
||
|
||
---
|
||
|
||
## 🔄 Checkout & Switch
|
||
|
||
```bash
|
||
git checkout dev # oder git switch dev – Wechselt zum Branch.
|
||
git checkout -f dev # Force Checkout: Wechselt den Branch und verwirft alle ungespeicherten lokalen Änderungen unwiderruflich! ⚠️
|
||
```
|
||
|
||
---
|
||
|
||
## 💻 VS Code Git-Optionen (UI)
|
||
|
||
VS Code bietet beim Branch-Wechsel oft drei intelligente Optionen an:
|
||
|
||
* **Migrate Changes ⭐**
|
||
* Nimmt deine aktuellen Änderungen einfach mit in den neuen Branch.
|
||
* (Intern: stash → switch → stash pop).
|
||
* **Stash & Checkout**
|
||
* Parkt deine Änderungen sicher im Stash und wechselt den Branch. Die Änderungen bleiben im Stash, bis du sie manuell wieder herausholst.
|
||
* **Force Checkout ⚠️**
|
||
* Wechselt den Branch und löscht deine aktuellen, ungespeicherten Änderungen. Nur nutzen, wenn die Arbeit weggeworfen werden kann.
|
||
|
||
---
|
||
|
||
## 🔄 Typischer Sync-Workflow
|
||
|
||
Um den Entwicklungs-Branch aktuell zu halten, nachdem dev in main gemerged wurde:
|
||
|
||
1. Auf dev entwickeln.
|
||
2. Merge dev → main für das Release.
|
||
3. Zurück auf dev wechseln:
|
||
```bash
|
||
git checkout dev
|
||
git merge main # (oder rebase), um den neuesten Stand vom Main wieder in Dev zu haben.
|
||
```
|
||
|
||
---
|
||
|
||
## 🧠 Merksätze
|
||
|
||
* **Merge** = Historien verbinden (Sicher & Dokumentiert).
|
||
* **Rebase** = Historie neu schreiben (Linear & Sauber).
|
||
* **Stash** = "Ich parke das mal kurz hier."
|
||
* **Migrate Changes** = Sicherer Branch-Wechsel mit "Gepäck".
|