Mac-Setup & Alltag: v0, GitHub, Vercel, Claude

Notfall: 3 Schritte (Abfotografieren)

Kurz-Check

1. Fakten in Text & Bild? → Cockpit (nirgends anders erdichten).
2. Layout / Code-Datei geändert? → In GitHub Desktop: zuerst Holen (andere) → arbeiten → Sichern mit kurzer Notiz → Hochschieben.
3. Rote Meldung, Konflikt, gar nichts geht? → Nicht raten: IT (oder B7 Hilfe unten). Kein force auf Haupt-Zweig.

Dahinter, ausführlich: Teil 2, Tabelle.

Zuerst Kurz in Alltagssprache, dann Schritt für Schritt — für Einrichtende und für Redaktion getrennt. Fachkürzel stehen in der Tabelle, nur wer mag, nutzt Terminal-Zeilen (unten, nach dem Einfach-Weg).

Firmen-Regel: Ein Center = ein Code-Ort (GitHub) + eine Live-Seite (Vercel) — sawmuedev. F2, ausführlich.

So geht’s am einfachsten (Kurz)

Wer	Fokus in Sätzen
Du richtest ein (einmal / pro Rechner)	Eigene Logins, niemand teilt Passwörter. Richtig eingeladen ins eine GitHub-Projekt (Repo) für dieses Center. Am liebsten GitHub Desktop für Klicks statt Tipp-Geheimnisse. Vercel ein Mal mit demselben GitHub-Projekt verbinden + Daten-Quelle eintragen. v0: Instructions A+B+C, dann im Chat in Sätzen sagen, was bauen soll.
Du arbeitest im Alltag (Redaktion)	Cockpit = Fakten + Veröffentliches. v0 = Beschreiben (Bild, Farben, „unter den News ein Karussell“). Wenn euer Ablauf Code mitschiebt: GitHub Desktop = Holen → arbeiten → Sichern → Hochladen (Fach: pull → commit → push). Claude = fragen statt Handbuch, nur wenn IT freigibt: MCP – Anleitung — kein Muss.

Merke: Cockpit = Inhalte. GitHub = Programm-Code der Webseite. Vercel = wo die Seite fürs Publikum läuft.

---

Begriffe (nur für Fach-Rede)

Begriff	Heißt so viel wie
Repository (Repo)	Ein Projektordner mit Versionsgeschichte — bei euch meist eins pro Center-Website.
Klonen	Den Stand aus GitHub einmal auf den Rechner laden (Kopie mit History).
Pull (holen)	Neueste Änderungen von GitHub auf euren Rechner holen — vor dem Arbeiten fast immer!
Commit	Einen Speicherpunkt mit kurzer Erklärung („was habe ich geändert?“) — lokal, noch nicht zwingend online.
Push (hochladen)	Commits nach GitHub schieben — ab dann sehen es andere (und ggf. Vercel baut neu).
Branch (Zweig)	Abzweigung für Test oder große Baustelle — optional; Anfänger können auf einem gemeinsamen Zweig bleiben, wenn eure IT das so will.
v0	Tool im Browser zum Layout/Code-Entwurf (Next.js) — Cockpit-Daten per API; A–Z für Redaktion.
Vercel	Hosting — baut eure Website aus dem GitHub-Repo; Einstellung NEXT_PUBLIC_DASHBOARD_URL muss passen.

Merksatz für Alltag: Cockpit = Inhalte (News, Shops, …). GitHub = Code der Seite. Beides muss passen, ist aber zwei Orte.

---

Teil 1 — Einmal einrichten (wenn du die Rechner vorbereitest)

Idee in einem Satz: Jede betroffene Person kann eigenhändig (mit Hilfe) Cockpit-Inhalte pflegen, in v0 in natürlichen Sätzen bauen, und Code in einem klaren **GitHub-**Ordner lassen; Vercel sorgt für die Live-Seite — alles klar getrennt.

Auf jedem Mac, der wirklich an Code mitarbeiten soll: lieber einmal richtig als jedes Mal rätseln.

1.0 — Voraussetzungen

• Die Berechtigung, am Mac Programme zu installieren — oder die IT erledigt das gemeinsam mit euch.
• Eine E-Mail-Adresse für GitHub — laut Firmenregel oft die Dienst-E-Mail.
• Kurz klären: Wer braucht v0? Wer Leserecht in Vercel? Wer nur Zugang zu GitHub? Wer Claude?

1.1 — Am einfachsten: Git zuerst mit der Maus (GitHub Desktop)

Für die meisten Teams ist das der bequemste Weg. Umgangssprachlich bedeutet das:

1. „Holen, was online schon neuer ist“ (technisch: pull)
2. Etwas in Dateien ändern (z. B. in Cursor, VS Code, …)
3. Eine Sicherung anlegen — mit einem kurzen Satz, was sich getan hat (technisch: commit)
4. Rüberschieben, damit alle und Vercel es sehen (technisch: push)

Installieren (einmal, am Mac): GitHub Desktop für den Mac herunterladen, starten, mit dem eigenen GitHub-Konto anmelden (Browser öffnet sich ggf. von selbst — Sätze lesen, Zustimmen, fertig). Dann das richtige Repository wählen (oder Klonen per Menü) — deine IT nennt dir die exakte https://github.com/sawmuedev/…-Adresse. Fertig — schwarzes Terminal braucht es dafür oft gar nicht; nur wenn eure Richtlinie anders lautet.

Erinnerung: Kein gemeinsames Passwort; eine Person = eine Einladung in das richtige GitHub-Projekt.

1.2 — Dann: Sätze, keine Handbücher (v0)

1. v0 im Browser, Konto wählen (Firmenlizenz).
2. Instructions A, B, C kopieren — Schritt D in der A–Z erklärt, wo die drei Blöcke hinkommen.
3. Cockpit-Slug und API-URL nur an den vorgegebenen Stellen ersetzen (nicht erfinden).
4. Im v0-Chat in einfachen Sätzen sagen, was passieren soll — z. B. „Startseite mit großem Foto, darunter 6 Karten für die Shops, alles fürs Handy tauglich“ — statt vorgefertigter **Programm-**Sprache.

1.3 — Vercel + Claude einrichten

• Vercel: Pro Center ein eigenes Projekt anlegen, das mit genau dem passenden GitHub-Repo in sawmuedev verbunden ist. In den Projekteinstellungen unter Environment Variables einmalig NEXT_PUBLIC_DASHBOARD_URL eintragen — das ist eure Cockpit-API-Adresse, ohne / am Ende. Danach baut Vercel bei jedem Push automatisch die Website neu. Ausführlicher: F2.
• Claude kann in normalen Sätzen Cockpit-Daten lesen und Inhalte zur Freigabe einreichen. Einfachster Weg: Remote-URL in Claude eintragen — kein Node.js, keine Installation, 2 Minuten. IT gibt URL + Secret weiter. Vollständige Anleitung: Claude & Cockpit verbinden → (dort: Weg A = Remote-URL zuerst). Claude kann außerdem Website-Dateien direkt bearbeiten (s. 1.3a unten).

1.3a — Claude: Dateizugriff einrichten (damit Claude Website-Dateien direkt bearbeiten kann)

Das ist die Vorbereitung für den Workflow „Redaktion baut und bearbeitet Websites direkt mit Claude“ — ohne v0, in normalen Sätzen.

Vollständige Anleitung mit allen Schritten: Website mit Claude bauen & bearbeiten

Kurzfassung (IT, einmal pro Mac):

1. Node.js installieren — nodejs.org/de → „LTS“ herunterladen und installieren (einfach durchklicken).
2. Claude Desktop muss bereits installiert und angemeldet sein (s. A7).
3. Das Repo muss als Ordner auf dem Mac liegen (s. 1.1).
4. Die Datei ~/Library/Application Support/Claude/claude_desktop_config.json anlegen oder ergänzen — mit folgendem Eintrag (Pfad anpassen):

 {
   "mcpServers": {
     "filesystem": {
       "command": "npx",
       "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/NAME/Documents/Arbeit/Center-Webs"]
     }
   }
 }

5. Claude Desktop vollständig beenden und neu starten.
6. Prüfen: in Claude tippen „Liste mir alle Dateien in meinem Website-Ordner auf“ — wenn Dateinamen erscheinen, funktioniert es.

1.4 — (Optional) Nur für Tipp-Profis / IT-Vorgabe: Terminal + Git-Grundlage

Wer kein GitHub Desktop will oder muss, trotzdem zuerst: kleine Werkzeuge für git — Apple-Befehlszeilenwerkzeuge (Teil der Xcode-Werkzeuge), damit im Terminal die gleichen Befehle laufen:

A1 — Apple Entwicklertools für Git (Command Line Tools)

1. Terminal öffnen (Programme → Dienstprogramme → Terminal).
2. Tippen: git --version und Enter.

• Wird installiert? an der Stelle erscheint ein Dialog → Installieren wählen, warten, fertig.
• Wird eine Version gezeigt (z. B. git version 2.x) — bereits da.

Falls xcode-select: note: no developer tools — die Installation aus dem Dialog abwarten. Danach git --version erneut prüfen.

A2 — Git Name und E-Mail (einmal pro Mac-Benutzer-Login)

Jede Person, die committet, braucht sichtbare Identität in der Historie:

git config --global user.name "Vorname Nachname"
git config --global user.email "eure@firma.de"

Wichtig: user.email idealerweise genau die E-Mail, die auch für euer GitHub-Konto genutzt wird (oder eure offizielle No-Reply-Adresse, falls ihr das so führt — einheitlich mit IT absprechen).

Prüfen:

git config --global --list

A3 — GitHub-Konto für jede Mitarbeiterin / jeden Mitarbeiter

1. https://github.com — Konto anlegen (falls noch fehlt) oder Firmen-SSO, falls eure Orga GitHub Enterprise so nutzt.
2. Zwei-Faktor-Authentifizierung (2FA) empfohlen (Sicherheits-Standard).
3. Admin in der Organisation sawmuedev lädt jede Person ein (Organization invite) oder trägt sie als Collaborator in den jeweiligen Center-Repos ein — siehe F2, Zugriff.

Niemals ein gemeinsames Passwort für alle — jede Person eigener GitHub-Login.

A4 — Anmeldung am Mac an GitHub für git (HTTPS, empfohlen für Einstieg)

Zwei gängige Wege — einen wählen und in der Firma einheitlich dokumentieren:

Variante 1 — GitHub im Browser (Credential Helper)
Beim ersten git push / git pull erscheint ggf. die Browser-Anmeldung — anmelden, fertig.

Variante 2 — GitHub CLI (optional, klarer für viele)
Nach Installation: gh auth login — Anweisungen am Bildschirm.

Falls „Authentication failed“: in GitHub → Settings → Developer settings → Personal access tokens (klassisch Fine-grained oder classic nach IT-Vorschrift) — niemals in Screenshots in Gruppenchats, nur in sichere Passwort-Manager / IT-Prozess.

A5 — Vercel (im Detail; Kurzfassung stand schon in 1.3)

1. Vercel-Konto/Team — euer Firmen-Workflow (Einladung, Rolle).
2. Pro Zentrum ein Projekt — verknüpft mit genau einem sawmuedev/…-Repo (F2).
3. In den Projekteinstellungen → Environment Variables:

• NEXT_PUBLIC_DASHBOARD_URL = eure API-Basis (z. B. https://dashboard.cockpit-os.de) ohne Schrägstrich am Ende.

4. Production-Deploy nach jeder wichtigen Änderung auf main (oder wie euer Branch-Standard heißt) prüfen — Vercel baut in der Regel automatisch nach push.

Redaktion braucht Vercel nur, wenn sie Vorschau-Links sehen will — reicht meist Leserecht oder Links von der IT. Nicht jede Person muss Vercel-Admin sein.

A7 — Claude (App) + optional Cockpit per MCP (Kopie mit IT durchgehen!)

• Claude als App (Desktop) von Anthropic / eurem Einkaufs-Kanal — Firmenrichtlinie für KI-Daten beachten.
• Soll mit Cockpit-Daten arbeiten: Claude & Cockpit verbinden (Anleitung) → — Weg A (empfohlen): Remote-URL + Secret in Claude eintragen, fertig. Kein Node.js, keine Installation. Weg B (Fallback): pnpm mcp:init im Repo (braucht Node.js). Vorsicht bei Push ins System.
• Nur für Personen, die dazu geschult und freigegeben sind — kein Muss für reine Inhaltspflege.

A8 — Editor für Code (empfohlen, nicht zwingend)

• Cursor, Visual Studio Code o. ä. — Datei → Ordner öffnen → geklontes Repo-Root.

A9 — Checkliste Einrichtung (abhaken, dann Redaktion informieren)

• git funktioniert, Name/E-Mail gesetzt
• Jede arbeitende Person in sawmuedev / in den nötigen Repos sichtbar eingeladen
• v0-Instructions A+B+C im Projekt, HIER_-Platzhalter ersetzt
• Vercel-Projekt + **NEXT_PUBLIC_DASHBOARD_URL**
• (Optional) Claude + (optional) MCP laut Doku, nur mit Freigabe
• (Optional, wenn Redaktion Claude zum Bearbeiten nutzt) Dateizugriff für Claude eingerichtet und geprüft — Anleitung 1.3a
• Redaktion den Einfach-Weg schicken: Teil 2 — zuerst GitHub Desktop (Tabelle) — Terminal nur wer mag / IT sagt

---

Teil 2 — Alltag: Code pflegen, ohne Geheim-Sprache

Cockpit = Fakten (News, Shops …). Hier = Dateien für die Webseite (Look, v0-Export, Einstellungen) — in einem **GitHub-**Ordner, den ihr schon in 1.1 kennengelernt habt.

2.1 — Einfachster Alltag: GitHub Desktop (empfohlen)

So kann es sich anfühlen (Menü-Namen leicht anders, je Version):

Du willst …	Umgangssprachlich	Ungefähr in GitHub Desktop
Das Projekt das erste Mal	„Den Ordner für mich ablegen“	File → Clone repository (URL von der IT) → Ziel-Ordner wählen, Klonen
Vor dem Arbeiten	„Was andere schon hochschoben, zu mir ziehen“	Fetch origin bzw. Pull origin (wenn vorgeschlagen)
Nach dem Ändern in Cursor/Editor	„Diese Änderung mit kurzer Notiz festhalten“	Unten Summary füllen, Description frei, Commit to main (o. euer Zweig), dann Push
Fertig für andere / Live-Build	„Rüberschieben“	Push origin — Vercel baut meist von allein

Beispiel für einen Commit-Kurztext (alltagstauglich): „Header: Logo etwas größer fürs Handy“ — kein Rätsel am nächsten Montag.

Neues Center, komplett eigene Adresse: kein „aus altem klonen und umbenennen“ — euer Ablauf F2 / IT; am bisherigen Repo ist der Einfach-Alltag: Holen → ändern → Sichern → Hochladen, wie in der Tabelle.

2.2 — (Optional) Dieselbe Sache für Tipp-Profis: Terminal

B0 — Vorbereiten: in welchem Ordner?

Legt pro Klonerei einen klaren Ordner an, z. B. Dokumente/Arbeit/Center-Webs — kein Mischen mit Fotos oder **E-Mail-**Downloads.

Im Terminal (Beispiel):

cd ~/Dokumente/Arbeit/Center-Webs

B1 — Repository klonen (wenn es auf GitHub schon existiert)

1. In GitHub im Browser: Repo öffnen, z. B. https://github.com/sawmuedev/website-euer-center-slug
2. Grüner Button Code — HTTPS-URL kopieren (sieht aus wie https://github.com/sawmuedev/website-....git).

Terminal:

git clone https://github.com/sawmuedev/website-euer-center-slug.git
cd website-euer-center-slug

Beim ersten Mal: ggf. anmelden (Browser/Token) — s. A4.

Fertig? Ihr seid im Ordner des Projekts. Den könnt ihr in Cursor/VS Code öffnen.

B2 — Vor dem Tippen: immer den neuesten Stand holen (pull)

Wenn andere schon gepusht haben — sonst entstehen Konflikte.

cd /pfad/zu/website-euer-center-slug
git pull

Wenn Already up to date — gut. Wenn viele Dateien kommen — warten, fertig, dann weitertippen.

B3 — Änderung machen und committen (lokal speichern mit Kommentar)

1. In eurem Editor eine oder mehrere Dateien speichern (übliches Speichern).
2. Terminal im Projektordner:

git status

• rot / untracked = Git sieht etwas Neues; rot modified = geändert.

Alles Wichtige stagen (zum Commit vormerken):

git add -A

(Will nur eine Datei: git add pfad/zur/datei.tsx)

1. Commit mit kurzer, verständlicher Nachricht — eine Zeile, was + grob warum:

git commit -m "Startseite: Teaser-Abstand für Handy anpassen"

Wenn nothing to commit — war nichts geändert oder vergessen zu speichern.

B4 — Hochladen nach GitHub (push)

git push

• Erstes Mal auf einem neuen Branch: kann git push -u origin branchname nötig sein (s. B5).

Dann: Vercel baut in der Regel automatisch (wenn an main/master o. euer Standard verbunden) — Vorschau-URL für euer Team wissen.

B5 — (Optional) Zweig (Branch) für Versuch / Entwurf

Wenn ihr nicht direkt die Hauptlinie anfassen wollt (Policy mit IT klären):

git pull
git checkout -b entwurf/beispiel-layout
# … arbeiten, committen …
git push -u origin entwurf/beispiel-layout

Zusammenführen in die Hauptlinie macht die IT / PR in GitHub — nicht nötig, wenn ihr alle auf main arbeiten dürft (kleine Teams geht oft so).

B6 — Aus einer bestehenden Center-Webs „etwas Neues“ (richtig einsortieren)

Was ihr wollt	Richtig	Falsch / nur mit IT
Inhalt (News, Preise, neuer Shop)	Cockpit	Nicht in v0 erdichten
Layout/Code für dieses Center weiterentwickeln	Im selben Repo: clonen, pull, ändern, commit, push (evtl. Branch)	Eigentümer-Repo wechseln
Komplett neues Center, eigene URL	Neues Repo + neues Vercel-Projekt — F2	Altes Repo copy-paste und doppelt anmelden (drift)
Auf bestehenden Code aufsetzen (Vorlage)	Nur nach IT-Vorgabe: z. B. GitHub „Use this template“ / leeres Repo von Vorlage	„Repo umbenennen“ oder Zwei Vercel → eins Repo ohne Abstimmung

Einfachster Alltag für euer altes, bestehendes Repo: git pull → ändern → git add → git commit → git push. Fertig.

B7 — Wenn’s hakt (Häufige Meldungen, kurz)

Meldung (sinngemäß)	Meist heißt es
Permission denied / 403	Kein Zugriff auf dieses Repo in sawmuedev — Admin bittet, einzuladen (oder falscher Account in Git).
Please commit your changes vor git pull	Ihr habt lokal was geändert. Einchecken (commit) oder mit Stash/Reset (mit IT) aufräumen, dann git pull.
CONFLICT	Zwei Personen, dieselbe Stelle. Nicht einfach „wegspeichern“ — [Konflikt in IT fragen] oder in Git-Handbüchern: Konflikte in Dateien per Editor auflösen (Marker <<<< entfernen, dann commit).
rejected: non-fast-forward	Jemand anderes war schneller. Vor erneutem push: git pull (oder git pull --rebase nach IT-Standard), Konflikte lösen, dann git push.

Generell: Wenn unklar, kein git push --force auf Haupt-Zweig ohne IT — das kann für andere destruktiv sein.

---

Teil 3 — Kurz-Checklisten (Lesezeichen / Druck)

Redaktion (Alltag, Maus zuerst)

• Fakten im Cockpit (nicht in v0 erdichten)
• Wenn an Code-Dateien: in GitHub Desktop (oder gelernt: Terminal) zuerst holen, was andere gestern taten
• Dann bauen / speichern, Kurztext für eure Sicherung, dann hochschieben
• Wenn was hakt oder unklar ist: IT fragen oder B7 — häufige Meldungen — kein force auf Haupt-Zweig ohne IT
• Ganz neues Center mit neuer Domäne = F2 / IT, kein stilles Doppel-Repo

Einmal-Einrichtung (abgehakt von der Person, die die Macs vorbereitet)

• GitHub Desktop (oder: Terminal-Pfad) + Zugang sawmuedev / passendes Repo pro Center
• v0-Instructions + Cockpit-Daten ersetzen (v0 A–Z)
• Vercel-Projekt + **NEXT_PUBLIC_DASHBOARD_URL**
• (Wenn vorgesehen) Claude + ggf. MCP
• Link an Redaktion: Teil 2 — Tabelle (GitHub Desktop)

Vertiefung v0 (ohne Code-Stress): v0-Website A–Z
Für viel Technik-Detail der API: Public API – Vertrag

---

Stand: inhaltlich abgestimmt mit der Firmen-Regel ein Center = ein Repo = ein Vercel (sawmuedev, F2).