kapteins-daagbok/.cursor/skills/merge/SKILL.md

name, description

name	description
merge	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:

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

git fetch origin

Vor dem Merge prüfen, wie weit der Branch hinter origin/master liegt:

git log --oneline HEAD..origin/master
git log --oneline origin/master..HEAD

4. Merge ausführen

Feature-Branch mit master synchronisieren (häuigster Fall):

git checkout <feature-branch>
git merge origin/master

Branch in master mergen (nur wenn User das ausdrücklich will — normalerweise passiert das via PR):

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:

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

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:

git add <file>

Merge abschließen (nur wenn User Commit verlangt hat):

git commit -m "$(cat <<'EOF'
Merge branch 'master' into <feature-branch>

EOF
)"

6. Verifizieren

Nach erfolgreichem Merge:

git status
git log --oneline -5

Relevante Checks je nach betroffenen Bereichen:

# 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