For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/web/updating-the-kit.md (or send Accept: text/markdown).
Ihre Kopie aktualisieren, wenn das Kit besser wird
Übernehmen Sie Verbesserungen aus dem Quell-Repository in Ihre Kopie — notieren Sie Ihren Ausgangspunkt, holen Sie den neuen Stand ab, mergen Sie ihn auf einem Branch und verifizieren Sie vor dem Deployment.
1. Notieren Sie, wovon Sie gestartet sind
Behandeln Sie ein Update als kleines Projekt, nicht als Einfügung: Sie vergleichen den Kit-Stand, den Sie haben, mit dem neueren, übertragen die Änderungen und testen auf einem Branch, bevor Sie deployen. Das funktioniert, egal ob Ihr Projekt ein Fork eines Kit-Repositorys ist — eine Kopie, die GitHub mit der Quelle verbunden hält — oder Code, den Sie in Ihre eigene App kopiert haben.
Schreiben Sie vor allem anderen eine Notiz in Ihrem Projekt mit drei Dingen: dem Kit-Commit, von dem Sie gestartet sind — dem SHA, Gits Kurzcode, der eine exakte Version identifiziert — dem Repository, das Sie erhalten haben (supastack-web, supastack-mobile, supastack-desktop oder das All-Platforms-Monorepo), und den Änderungen, die Sie bereits selbst vorgenommen haben.
Die Kit-Repositorys und das Monorepo haben unterschiedliche Historien — mergen Sie daher nie einen Branch aus dem einen in einen Fork des anderen. Wenn Sie nie einen Start-SHA notiert haben, finden Sie mit git merge-base in einem Fork die nächstgelegene gemeinsame Version, oder identifizieren Sie bei einer selektiven Übernahme die zuletzt kopierten Dateien und Tests — und prüfen Sie bei unsicherer Basis einen größeren Diff.
2. Den neuen Stand abrufen und mergen
Führen Sie die folgenden Befehle in einem Terminal innerhalb Ihres Projektordners aus — mit gespeicherter und committeter Arbeit, also einem sauberen Arbeitsbaum, damit nichts Halbfertiges in den Merge gerät. Wörter in spitzen Klammern sind Platzhalter: Ersetzen Sie das gesamte <thing> durch Ihre eigenen Werte. Die gezeigte GitHub-Adresse ist ein Beispiel; verwenden Sie die Adresse des Repositorys, das Sie geforkt haben.
Was die Zeilen tun: git remote add bringt Ihrer Kopie eine zweite Adresse namens kit-upstream bei — das Kit-Repository — und git fetch lädt dessen neuesten Stand herunter, ohne Ihre Dateien anzufassen. git switch -c erstellt einen separaten Upgrade-Branch, damit Ihr Hauptbranch während der Prüfung unberührt bleibt. git log listet die Commits, die Sie übernehmen wollen, und git diff --stat fasst zusammen, welche Dateien sich geändert haben; lesen Sie für die Module, die Sie nutzen, den vollständigen Diff, nicht nur die Commit-Titel. git merge bringt den neuen Code in den Upgrade-Branch.
Wenn Git meldet, dass der Remote kit-upstream bereits existiert, überspringen Sie die Zeile remote add und fahren mit git fetch fort. <previous-kit-sha> ist der Start-SHA, den Sie in Schritt 1 notiert haben.
# Upstream is the platform repository you forked — substitute its real URL
# (supastack-web shown; use supastack-mobile or supastack-desktop as fits).
git remote add kit-upstream https://github.com/<org>/supastack-web.git
git fetch kit-upstream
git switch -c upgrade/kit-update
git log --oneline <previous-kit-sha>..kit-upstream/main
git diff --stat <previous-kit-sha>..kit-upstream/main
git merge kit-upstream/main3. Konflikte lösen, ohne Ihre Arbeit zu verlieren
Ein Konflikt bedeutet, dass beide Seiten dieselben Zeilen geändert haben: Das Kit ist weitergegangen, und Sie haben dieselbe Stelle angepasst. Git hält den Merge an und markiert die Datei — es bittet Sie um eine Entscheidung, es meldet keinen Schaden.
Öffnen Sie jede markierte Datei in Ihrem Editor und entscheiden Sie Zeile für Zeile: Behalten Sie die eigenen Texte, Namen und Einstellungen Ihres Produkts und übernehmen Sie die Fehlerbehebungen und strukturellen Änderungen des Kits. Lösen Sie einen Konflikt niemals, indem Sie eine angepasste Datei komplett durch die neue Version des Kits ersetzen — das löscht Ihre Arbeit. Lösen Sie innerhalb des Upgrade-Branches und führen Sie die Tests für jeden gelösten Bereich aus, bevor Sie weitermachen.
Wenn der Merge schiefgeht, bringt git merge --abort den Branch in den Zustand vor dem Merge zurück. Nichts in diesem Ablauf ändert Ihren Hauptbranch oder Ihr Deployment, bis Sie den Upgrade-Branch selbst mergen.
4. Daten aktualisieren und in der richtigen Reihenfolge deployen
Neue Kit-Stände können die Datenbank ändern. Lesen Sie die neuen Dateien in packages/db/drizzle/ — dem Migrationsordner — und sichern Sie die Produktionsdaten, bevor Sie Migrationen anwenden; testen Sie sie zuerst gegen eine Wegwerfkopie. Deployen Sie kompatible Schemaänderungen vor dem Code, der sie braucht: Wenn eine Migration Daten entfernt oder umformt, kann ein Zurückrollen des App-Codes allein das alte Schema nicht wiederherstellen.
Vergleichen Sie das neue .env.example mit Ihren eigenen Einstellungen und ergänzen Sie neu geforderte Werte in Ihrem Hosting-Dashboard. .env-Dateien enthalten Geheimnisse und werden nie in Git committet — Sie erstellen sie von Hand auf jeder Maschine und jedem Deployment neu, und sie bleiben aus NEXT_PUBLIC_- und EXPO_PUBLIC_-Werten heraus.
Führen Sie vor dem Deployment die eigenen Verifizierungstore des Kits aus. Im All-Platforms-Monorepo führt corepack pnpm check:local Lint, Typecheck, die Unit-Tests und eine Formatprüfung ohne kostenpflichtige Zugangsdaten aus; corepack pnpm verify:local ergänzt den Produktionsbuild und die Browser-Testsuiten. In einem Fork einer einzelnen Oberfläche führen Sie die eigenen Test- und Build-Befehle dieses Repositorys aus. Machen Sie danach einen Staging-Rundgang: Melden Sie sich an, probieren Sie einen zweiten Workspace und durchlaufen Sie die zentrale Nutzerreise Ihres Produkts.
Wenn alles besteht, notieren Sie den akzeptierten Ziel-SHA und die Konflikte, die Sie gelöst haben — diese Notiz ist die Ausgangsbasis für das nächste Update.
corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local5. Wenn Sie Teile kopiert statt geforkt haben
Eine selektive Übernahme — das Kopieren von Kit-Modulen in eine bestehende App — teilt keine Git-Historie mit dem Kit, daher kann git merge nicht helfen. Vergleichen Sie stattdessen den alten Quell-SHA mit dem Ziel-Quell-SHA und portieren Sie nur die Änderungen, die Ihren übernommenen Ausschnitt berühren.
Prüfen Sie die öffentlichen Typen des Moduls, das Persistenzschema und die Migrationen, den Server-Aufrufer, die Konfiguration, die Tests und die Dokumentation als eine Einheit — eine Änderung in einem Paket kann an anderer Stelle eine passende Route oder Umgebungsänderung erfordern, und das Kopieren eines einzelnen Helfers kann den Rest auf einem veralteten Vertrag zurücklassen. Führen Sie eine kurze Anpassungsnotiz — welche Kit-Dateien Sie übernommen, welche übersprungen und was Sie geändert haben — damit das nächste Update Ihre Entscheidungen nachvollziehen kann.
Wenn ein Update etwas in Ihrer laufenden Kopie beschädigt, arbeiten Sie die Fehlerbehebungs-Anleitung durch, bevor Sie Ihre eigenen Änderungen rückgängig machen.