> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Werk uw kopie bij wanneer de kit verbetert Breng verbeteringen uit de bronrepository over naar uw kopie — leg uw uitgangspunt vast, haal de nieuwe revisie op, merge die op een branch en verifieer vóór het deployen. ## 1. Leg uw uitgangspunt vast Behandel een update als een klein project, niet als een plakactie: u vergelijkt de kitrevisie die u heeft met de nieuwere, draagt de wijzigingen over en test op een branch voordat u deployt. Dit werkt of uw project nu een fork is van een kitrepository — een kopie die GitHub met de bron verbonden houdt — of code die u in uw eigen app heeft gekopieerd. Schrijf allereerst een notitie in uw project met drie dingen: de kitcommit waar u mee begon — de SHA, de korte code van Git die één exacte versie identificeert — de repository die u heeft ontvangen (supastack-web, supastack-mobile, supastack-desktop of de All Platforms-monorepo), en de wijzigingen die u zelf al heeft gemaakt. De kitrepositories en de monorepo hebben verschillende geschiedenissen, dus merge nooit een branch van de ene in een fork van de andere. Als u nooit een begin-SHA heeft vastgelegd, vind dan in een fork de dichtstbijzijnde gedeelde versie met git merge-base, of identificeer bij een selectieve overname de laatste bestanden en tests die u heeft gekopieerd — en bekijk een bredere diff wanneer de exacte basislijn onzeker is. ## 2. Haal de nieuwe revisie op en merge die Voer de onderstaande opdrachten uit in een terminal in uw projectmap, met uw werk opgeslagen en gecommit — een schone working tree, zodat er niets halfafs in de merge terechtkomt. Woorden tussen punthaken zijn invulsjablonen: zet uw eigen waarden in de plaats van het hele . Het getoonde GitHub-adres is een placeholder; gebruik het adres van de repository die u heeft geforkt. Wat de regels doen: git remote add leert uw kopie een tweede adres met de naam kit-upstream — de kitrepository — en git fetch downloadt de nieuwste staat zonder uw bestanden aan te raken. git switch -c maakt een aparte upgradebranch aan zodat uw hoofdbranch onaangeroerd blijft terwijl u controleert. git log toont de commits die u gaat overnemen en git diff --stat vat samen welke bestanden zijn gewijzigd; lees de volledige diff voor de modules die u gebruikt, niet alleen de committitels. git merge brengt de nieuwe code in de upgradebranch. Als Git meldt dat de kit-upstream-remote al bestaat, sla dan de regel remote add over en ga verder met git fetch. is de begin-SHA die u in stap 1 heeft vastgelegd. ``` # 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//supastack-web.git git fetch kit-upstream git switch -c upgrade/kit-update git log --oneline ..kit-upstream/main git diff --stat ..kit-upstream/main git merge kit-upstream/main ``` ## 3. Los conflicten op zonder uw werk te verliezen Een conflict betekent dat beide kanten dezelfde regels hebben gewijzigd: de kit is verdergegaan en u heeft dezelfde plek aangepast. Git pauzeert de merge en markeert het bestand — het vraagt u te kiezen, het rapporteert geen schade. Open elk gemarkeerd bestand in uw editor en beslis regel voor regel: behoud de eigen tekst, namen en instellingen van uw product en neem de fixes en structurele wijzigingen van de kit over. Los een conflict nooit op door een bestand dat u heeft aangepast te vervangen door de hele nieuwe versie van de kit — dat wist uw werk. Los op binnen de upgradebranch en voer de tests voor elk opgelost gebied uit voordat u doorgaat. Als de merge misgaat, brengt git merge --abort de branch terug naar de staat van vóór de merge. Niets in deze stroom verandert uw hoofdbranch of uw deployment totdat u de upgradebranch zelf merget. ## 4. Werk data bij en deploy in de juiste volgorde Nieuwe kitrevisies kunnen de database wijzigen. Lees de nieuwe bestanden in packages/db/drizzle/ — de migratiemap — en maak een back-up van productiedata voordat u migraties toepast; test ze eerst tegen een wegwerpkopie. Deploy compatibele schemawijzigingen vóór de code die ze nodig heeft: als een migratie data verwijdert of hervormt, kan het terugdraaien van alleen appcode het oude schema niet herstellen. Vergelijk het nieuwe .env.example met uw eigen instellingen en voeg nieuw vereiste waarden toe in uw hostingdashboard. .env-bestanden bevatten geheimen en worden nooit naar Git gecommit — u maakt ze met de hand opnieuw op elke machine en deployment, en ze blijven uit NEXT_PUBLIC_- en EXPO_PUBLIC_-waarden. Voer vóór het deployen de eigen verificatiecontroles van de kit uit. In de All Platforms-monorepo voert corepack pnpm check:local lint, typecheck, de unittests en een formaatcontrole uit zonder betaalde referenties; corepack pnpm verify:local voegt de productiebuild en de browsertestsuites toe. Voer in een fork van één oppervlak de eigen test- en buildopdrachten van die repository uit. Doe daarna een staging-smoketest: meld u aan, probeer een tweede workspace en doorloop de belangrijkste gebruikersreis van uw product. Wanneer alles slaagt, noteer dan de geaccepteerde doel-SHA en de conflicten die u heeft opgelost — die notitie is de beginbasislijn voor de volgende update. ``` corepack pnpm check:local # fuller gate: adds the production build and browser suites corepack pnpm verify:local ``` ## 5. Als u stukken heeft gekopieerd in plaats van geforkt Een selectieve overname — kitmodules in een bestaande app kopiëren — deelt geen Git-geschiedenis met de kit, dus git merge kan niet helpen. Vergelijk in plaats daarvan de oude bron-SHA met de doel-bron-SHA en port alleen de wijzigingen die uw overgenomen deel raken. Beoordeel de publieke types van de module, het persistentieschema en de migraties, de serveraanroeper, de configuratie, de tests en de docs als één geheel — een wijziging in een package kan elders een bijpassende route- of omgevingswijziging vereisen, en het kopiëren van een enkele helper kan de rest op een verouderd contract achterlaten. Houd een korte aanpassingsnotitie bij — welke kitbestanden u heeft genomen, welke u heeft overgeslagen, wat u heeft gewijzigd — zodat de volgende update uw keuzes kan herhalen. Als een update iets in uw draaiende kopie breekt, doorloop dan de probleemoplossingsgids voordat u uw eigen wijzigingen ongedaan maakt. [Los een probleem na een update op](https://supastack.dev/nl/docs/web/troubleshooting.md) ## Volgende [Moduleoverzicht](https://supastack.dev/nl/docs/modules.md)