183 lines
4.9 KiB
Markdown
183 lines
4.9 KiB
Markdown
---
|
|
name: merge
|
|
description: >-
|
|
Merge Git branches safely — fetch latest, merge or rebase onto master, resolve
|
|
conflicts intelligently, and verify the result. Use when the user asks to merge
|
|
branches, sync with master, resolve merge conflicts, or bring a feature branch
|
|
up to date.
|
|
---
|
|
|
|
# Git Merge
|
|
|
|
Führe Branch-Merges sicher und nachvollziehbar aus. Für PR-Review, CI und
|
|
Comment-Triage siehe den **babysit**-Skill — dieser Skill deckt die Git-Merge-
|
|
Operation selbst ab.
|
|
|
|
## Projekt-Kontext
|
|
|
|
- **Basis-Branch:** `master` (nicht `main`)
|
|
- **Monorepo:** `client/` (React PWA) und `server/` (Express API) — Konflikte
|
|
können in beiden liegen
|
|
|
|
## Sicherheitsregeln (immer einhalten)
|
|
|
|
- **Niemals** `git config` ändern
|
|
- **Niemals** `--no-verify`, `--no-gpg-sign` o.ä. ohne explizite Anfrage
|
|
- **Niemals** `push --force` auf `master` — bei Bedarf warnen und abbrechen
|
|
- **Niemals** destruktive Befehle (`reset --hard`, `clean -fd`) ohne explizite Anfrage
|
|
- **Niemals** interaktive Git-Befehle (`-i`-Flags) — nicht unterstützt
|
|
- **Kein Commit** ohne explizite Anfrage des Users
|
|
- **Kein Push** ohne explizite Anfrage des Users
|
|
|
|
## Workflow
|
|
|
|
### 1. Ausgangslage klären
|
|
|
|
Parallel ausführen:
|
|
|
|
```bash
|
|
git status
|
|
git branch -vv
|
|
git log --oneline -5
|
|
```
|
|
|
|
Ermittle:
|
|
|
|
- Aktueller Branch
|
|
- Ziel-Branch (Standard: `master`)
|
|
- Ob uncommittete Änderungen vorliegen
|
|
- Ob der Branch einen Remote-Tracking-Branch hat
|
|
|
|
**Bei uncommitteten Änderungen:** Stashen (`git stash push -m "pre-merge"`) nur
|
|
mit Zustimmung oder wenn der User es verlangt hat. Sonst stoppen und melden.
|
|
|
|
### 2. Merge-Strategie wählen
|
|
|
|
| Situation | Empfehlung |
|
|
|-----------|------------|
|
|
| Feature-Branch aktuell halten | `git merge origin/master` (Merge-Commit) |
|
|
| Linearer Verlauf gewünscht | `git rebase origin/master` (nur wenn User Rebase verlangt) |
|
|
| Zwei Feature-Branches zusammenführen | `git merge <branch>` auf Ziel-Branch |
|
|
|
|
**Standard:** Merge (nicht Rebase), es sei denn der User verlangt Rebase.
|
|
|
|
### 3. Remote aktualisieren
|
|
|
|
```bash
|
|
git fetch origin
|
|
```
|
|
|
|
Vor dem Merge prüfen, wie weit der Branch hinter `origin/master` liegt:
|
|
|
|
```bash
|
|
git log --oneline HEAD..origin/master
|
|
git log --oneline origin/master..HEAD
|
|
```
|
|
|
|
### 4. Merge ausführen
|
|
|
|
**Feature-Branch mit master synchronisieren** (häuigster Fall):
|
|
|
|
```bash
|
|
git checkout <feature-branch>
|
|
git merge origin/master
|
|
```
|
|
|
|
**Branch in master mergen** (nur wenn User das ausdrücklich will — normalerweise
|
|
passiert das via PR):
|
|
|
|
```bash
|
|
git checkout master
|
|
git pull origin master
|
|
git merge <feature-branch>
|
|
```
|
|
|
|
Merge-Commit-Nachricht kurz und sachlich halten, z.B.:
|
|
`Merge branch 'master' into feature/push-notifications-owner`
|
|
|
|
### 5. Konflikte lösen
|
|
|
|
Konfliktdateien finden:
|
|
|
|
```bash
|
|
git diff --name-only --diff-filter=U
|
|
```
|
|
|
|
**Pro Konfliktdatei:**
|
|
|
|
1. Datei lesen und beide Seiten verstehen (HEAD = eigener Branch, incoming = gemergter Branch)
|
|
2. Intent beider Änderungen erhalten — nicht blind eine Seite wählen
|
|
3. Konfliktmarker entfernen (`<<<<<<<`, `=======`, `>>>>>>>`)
|
|
4. Bei widersprüchlicher Intent: Merge abbrechen und User fragen
|
|
|
|
```bash
|
|
git merge --abort # oder: git rebase --abort
|
|
```
|
|
|
|
**Typische Konflikt-Muster in diesem Projekt:**
|
|
|
|
| Bereich | Hinweis |
|
|
|---------|---------|
|
|
| `package-lock.json` | Nach manueller Lösung `npm install` im betroffenen Paket (`client/` oder `server/`) ausführen |
|
|
| i18n (`client/src/i18n/`) | Beide Sprachkeys (DE + EN) behalten, keine Keys verlieren |
|
|
| Prisma/Schema | Migrationen beider Seiten zusammenführen, nicht überschreiben |
|
|
| Verschlüsselung/Auth | Vorsichtig — keine Sicherheitslogik stillschweigend vereinfachen |
|
|
|
|
Nach jeder gelösten Datei:
|
|
|
|
```bash
|
|
git add <file>
|
|
```
|
|
|
|
Merge abschließen (nur wenn User Commit verlangt hat):
|
|
|
|
```bash
|
|
git commit -m "$(cat <<'EOF'
|
|
Merge branch 'master' into <feature-branch>
|
|
|
|
EOF
|
|
)"
|
|
```
|
|
|
|
### 6. Verifizieren
|
|
|
|
Nach erfolgreichem Merge:
|
|
|
|
```bash
|
|
git status
|
|
git log --oneline -5
|
|
```
|
|
|
|
Relevante Checks je nach betroffenen Bereichen:
|
|
|
|
```bash
|
|
# Client
|
|
cd client && npm run build
|
|
|
|
# Server
|
|
cd server && npm run build
|
|
```
|
|
|
|
Bei Lockfile-Konflikten oder Dependency-Änderungen: Build in beiden Paketen prüfen.
|
|
|
|
### 7. Abschluss
|
|
|
|
- Ergebnis dem User mitteilen: welche Branches, wie viele Konflikte, was gelöst wurde
|
|
- Bei `git stash`: erinnern, Stash wieder anzuwenden (`git stash pop`)
|
|
- Push nur auf explizite Anfrage: `git push origin <branch>`
|
|
|
|
## Wann abbrechen und fragen
|
|
|
|
- Widersprüchliche fachliche Intent (z.B. beide Seiten ändern dieselbe Logik unterschiedlich)
|
|
- Konflikte in Krypto-, Auth- oder Sync-Kernlogik ohne klares „richtig“
|
|
- Merge würde `.env`, Credentials oder Secrets einschließen
|
|
- User wollte nur Status prüfen, nicht tatsächlich mergen
|
|
|
|
## Abgrenzung zu anderen Skills
|
|
|
|
| Skill | Wann |
|
|
|-------|------|
|
|
| **merge** (dieser) | Git merge/rebase, Konflikte, Branch sync |
|
|
| **babysit** | PR merge-ready: Comments, CI, PR-Konflikte im PR-Kontext |
|
|
| **creating-pull-requests** | PR erstellen und pushen |
|