Jetzt setzt sich alles zusammen: Commits, Branches, origin, der Morgen-Merge, der Worktree. Diese Lektion geht den Weg eines Prototyps von der Idee bis zum eigenen Merge auf master — mit den echten Befehlen, in der Reihenfolge, in der du sie tippst. Und sie erklärt, warum du bei trybe selbst mergen darfst, und was genau deshalb vorher zu prüfen ist.
master ist Produktion
Im trybe-Repo liegt kein „Staging" dazwischen: Ein Push auf master startet zwei Abläufe, die die Frontends zu Netlify und das Backend samt Migrationen zu Laravel Cloud bringen. Eine Prüfung, die dich vorher aufhält, gibt es seit August nicht mehr — geprüft wird von der Person, die mergt. Das bist du.
Für Prototypen ist das entschärft. prototypes/ hat keinen Netlify-Eintrag, wird von keinem
Deploy angefasst und von make check übersprungen. Ein halbfertiger Prototyp auf master
stört niemanden; er liegt dort als klickbare Spec, bis jemand daraus das echte Feature baut.
Klapp dich durch den Baum, um zu sehen, was wohin geht.
Du mergst proto/notes auf master und pushst. Was passiert mit dem Notes-Prototyp?
Der Anfang: frisch von master
Ein neuer Prototyp beginnt immer auf dem aktuellen master. Erst pull, dann der Branch — ein
Branch, der von einem alten master abzweigt, fängt mit einem Merge-Rückstand an. Der Branch
heißt proto/<name>, der Ordner prototypes/<name>, das Paket proto-<name>; alle drei
tragen denselben Namen in Kleinbuchstaben mit Bindestrichen.
Enter führt aus · Tab vervollständigt den nächsten Befehl · Ausgaben gekürzt, Kennungen sind Beispielwerte
Warum git pull, bevor du den Branch anlegst?
Unterwegs: committen, pushen, master holen
Drei Gewohnheiten tragen den Alltag. Committen, sobald etwas läuft — nicht am Abend
alles auf einmal, sondern je Stück: „Booklet: Seitenleiste mit Kapiteln", „Booklet: Cover
wählbar". Kleine Commits lassen sich lesen und einzeln zurücknehmen. Pushen mindestens
täglich — als Backup und damit der Branch auf GitHub sichtbar ist. Und master holen
jeden Morgen, wie in der Merge-Lektion; bringt master neue Pakete mit, danach pnpm install.
Enter führt aus · Tab vervollständigt den nächsten Befehl · Ausgaben gekürzt
Nach dem Morgen-Merge startet der Prototyp nicht mehr: „Cannot find module '@base-ui/react'“. Was ist passiert?
Am Ende: prüfen, mergen, pushen
Der Prototyp ist fertig genug, um als Spec zu dienen. Jetzt kommt er auf master — und weil du das selbst tust, ist die Prüfung vorher deine. Für einen Prototyp heißt das: Typecheck (der Code hängt zusammen), Lint (keine toten Importe), Smoke (jede Fläche rendert, die Konsole schweigt), und ein Blick im Browser. Tests gibt es für Prototypen nicht, mit Absicht.
Dann der Merge in Gegenrichtung: auf master stehend deinen Branch hineinholen. --no-ff
sorgt dafür, dass ein Merge-Commit entsteht, auch wenn Git den Zettel einfach vorrücken
könnte — in der Historie steht dann „hier kam der Booklet-Prototyp herein", statt dass
deine Commits unsichtbar in master aufgehen.
Enter führt aus · Tab vervollständigt den nächsten Befehl · Ausgaben gekürzt
Der ganze Weg eines Prototyps, von der Idee bis master. Bring die Schritte in die richtige Ordnung.
- 1git switch master && git pull
- 2git switch -c proto/<name> (oder git worktree add … -b proto/<name>)
- 3cp -R prototypes/_template prototypes/<name>, Name und Port anpassen, pnpm install
- 4Bauen: kleine Commits, täglich git push
- 5Jeden Morgen: git fetch, git merge origin/master, bei Bedarf pnpm install
- 6Fertig: typecheck, lint, smoke, im Browser ansehen
- 7git switch master && git pull, dann git merge --no-ff proto/<name>
- 8git push, danach den Branch löschen
Häufige Fragen
Ich habe auf master losgelegt statt auf einem Branch und schon drei Commits gemacht.
Solange nichts gepusht ist: git switch -c proto/<name> nimmt dich samt der drei Commits auf den neuen Branch. Danach zeigt dein lokaler master noch auf den letzten der drei — git switch master && git reset --hard origin/master setzt ihn auf den GitHub-Stand zurück. Ist schon gepusht: Johannes anrufen, bevor du irgendetwas zurücksetzt.
Mein Prototyp braucht eine Component, die es in ui-web nicht gibt.
Lokal bauen, in app/components/ des Prototyps. Wird sie später produktreif, extrahiert sie jemand mit Review in die Library. Nur wenn es wirklich nicht anders geht, direkt in packages/ui-web — dann mit dem Kommentar PROTO(<name>) markieren, und der Merge ist ein Deploy: make check-web, anschauen, Johannes zeigen.
Nach dem Merge habe ich den Branch gelöscht. Ist der Prototyp weg?
Nein, er liegt in master unter prototypes/<name>. Der Branch war nur der Zettel; die Commits sind über den Merge-Commit in master erreichbar. git log --oneline zeigt sie weiterhin.
Wann ein Worktree, wann einfach ein Branch?
Ein Branch reicht, wenn du an einer Sache arbeitest. Ein Worktree lohnt sich, sobald du zwei Dinge parallel hast — den Notes-Prototyp und einen Zwei-Minuten-Fix im Calendar —, oder wenn Claude Code in einem Ordner läuft, während du in einem anderen editierst. Faustregel: Wenn du git stash tippen willst, wäre ein Worktree besser gewesen.
Muss ich bei jedem Prototyp master am Ende wirklich selbst mergen?
Ja, das ist die Abmachung: Unter prototypes/ kannst du nichts kaputt machen, also gehört der Merge dir. Ein Pull Request lohnt sich, wenn dein Branch Dateien außerhalb von prototypes/ berührt oder du unsicher bist — gh pr create --base master --fill, und Johannes mergt.
Wie sehe ich, was mein Branch alles geändert hat, bevor ich merge?
git diff --stat master...proto/<name> zeigt die Dateien mit Umfang, git log --oneline master..proto/<name> die Commits. Steht in der Dateiliste etwas außerhalb von prototypes/, weißt du, dass der Merge ein Deploy ist.