---
name: feedback_git_fetch_before_branch_work
description: "Vor JEDER Branch-/Code-Arbeit in einem geteilten Repo erst `git fetch` + gegen origin/main prüfen — nie auf stale local main bauen"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 936c7c70-7075-423c-9705-8e980062e6bc
---

Am 2026-05-31 habe ich in `/root/projekte/Kadi-v2` stundenlang KAR-629/630-„Foundations" gebaut — auf einem lokalen `main` von vor den Merges #103/#104 (28.05.). Beide PRs waren längst in `origin/main` gemerged; meine Arbeit war komplettes Duplikat, meine „PR #105" ein Dublikat der gemergten #104 (musste geschlossen + Remote-Branch gelöscht werden). `contrast.ts` schien „zu fehlen", existierte aber in main. Hätte ich zu Beginn `git fetch` gemacht, wäre die ganze Fehlkette nicht passiert.

**Why:** In einem Repo, an dem auch andere/frühere Sessions pushen (KADiCon/Kadi-v2), driftet local main schnell. Auf stale main zu branchen produziert Dubletten, Phantom-„fehlende" Files und Merge-Konflikte — und verleitet zu Falschmeldungen.

**How to apply:** Erster Schritt bei Repo-Arbeit IMMER: `git fetch origin` und Abgleich (`git log --oneline main..origin/main`, `git rev-parse main origin/main`). Wenn local hinterherhängt: nach Kais-Go `git reset --hard origin/main` (reset ist hook-geschützt). Branch-Existenz/PR-Status via `gh`/GitHub-MCP gegen den ECHTEN Remote prüfen, bevor ich neue Arbeit anfange oder Fortschritt melde. Verwandt: [[feedback_verify_writes_landed_before_claiming_green]].