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 /it/docs/web/updating-the-kit.md (or send Accept: text/markdown).
Aggiorna la tua copia quando il kit migliora
Porta i miglioramenti dal repository sorgente nella tua copia — registra il tuo punto di partenza, scarica la nuova revisione, fai merge su un branch e verifica prima del deploy.
1. Registra da dove sei partito
Tratta un aggiornamento come un piccolo progetto, non come un incolla: confronti la revisione del kit che hai con quella più nuova, porti le modifiche e testi su un branch prima del deploy. Funziona sia che il tuo progetto sia un fork di un repository del kit — una copia che GitHub tiene collegata alla sorgente — sia codice che hai copiato nella tua app.
Prima di ogni altra cosa, scrivi una nota nel tuo progetto con tre cose: il commit del kit da cui sei partito — lo SHA, il codice breve di Git che identifica una versione esatta — il repository che hai ricevuto (supastack-web, supastack-mobile, supastack-desktop o il monorepo All Platforms) e le modifiche che hai già fatto tu.
I repository del kit e il monorepo hanno cronologie diverse, quindi non fare mai merge di un branch da uno nell'altro fork. Se non hai mai registrato uno SHA di partenza, trova la versione condivisa più vicina con git merge-base in un fork, oppure identifica gli ultimi file e test che hai copiato in un'adozione selettiva — ed esamina un diff più ampio quando la baseline esatta è incerta.
2. Scarica e fai merge della nuova revisione
Esegui i comandi qui sotto in un terminale dentro la cartella del progetto, con il tuo lavoro salvato e committato — un working tree pulito, così niente di fatto a metà finisce nel merge. Le parole dentro le parentesi angolari sono modelli da sostituire: metti i tuoi valori al posto dell'intero <thing>. L'indirizzo GitHub mostrato è un segnaposto; usa l'indirizzo del repository che hai forkato.
Cosa fanno le righe: git remote add insegna alla tua copia un secondo indirizzo chiamato kit-upstream — il repository del kit — e git fetch ne scarica lo stato più recente senza toccare i tuoi file. git switch -c crea un branch di upgrade separato così il tuo branch principale resta intatto mentre esamini. git log elenca i commit che stai per prendere e git diff --stat riassume quali file sono cambiati; leggi il diff completo per i moduli che usi, non solo i titoli dei commit. git merge porta il nuovo codice nel branch di upgrade.
Se Git segnala che il remote kit-upstream esiste già, salta la riga remote add e continua con git fetch. <previous-kit-sha> è lo SHA di partenza che hai registrato al passaggio 1.
# 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. Risolvi i conflitti senza perdere il tuo lavoro
Un conflitto significa che entrambe le parti hanno cambiato le stesse righe: il kit è andato avanti e tu hai personalizzato lo stesso punto. Git mette in pausa il merge e marca il file — ti sta chiedendo di scegliere, non sta segnalando un danno.
Apri ogni file marcato nell'editor e decidi riga per riga: tieni testo, nomi e impostazioni propri del tuo prodotto, e prendi le correzioni e le modifiche strutturali del kit. Non risolvere mai un conflitto sostituendo un file che hai personalizzato con l'intera nuova versione del kit — così cancelli il tuo lavoro. Risolvi dentro il branch di upgrade ed esegui i test per ogni area risolta prima di continuare.
Se il merge va male, git merge --abort riporta il branch allo stato pre-merge. Niente in questo flusso cambia il tuo branch principale o il tuo deployment finché non fai tu stesso il merge del branch di upgrade.
4. Aggiorna i dati e distribuisci nell'ordine giusto
Le nuove revisioni del kit possono cambiare il database. Leggi i nuovi file in packages/db/drizzle/ — la cartella delle migrazioni — e fai il backup dei dati di produzione prima di applicare le migrazioni; testale prima su una copia usa e getta. Distribuisci le modifiche di schema compatibili prima del codice che ne ha bisogno: se una migrazione rimuove o rimodella dati, tornare indietro solo con il codice dell'app non può ripristinare il vecchio schema.
Confronta il nuovo .env.example con le tue impostazioni e aggiungi i valori appena richiesti nella dashboard del tuo hosting. I file .env contengono segreti e non vanno mai in commit su Git — li ricrei a mano su ogni macchina e deployment, e restano fuori dai valori NEXT_PUBLIC_ ed EXPO_PUBLIC_.
Prima del deploy, esegui i gate di verifica del kit. Nel monorepo All Platforms, corepack pnpm check:local esegue lint, typecheck, i test unitari e un controllo di formato senza credenziali a pagamento; corepack pnpm verify:local aggiunge la build di produzione e le suite di test nel browser. In un fork a superficie singola, esegui i comandi di test e build di quel repository. Poi fai un giro di smoke test su staging: accedi, prova un secondo workspace ed esegui il percorso utente principale del tuo prodotto.
Quando tutto passa, annota lo SHA di destinazione accettato e i conflitti che hai risolto — quella nota è la baseline di partenza per il prossimo aggiornamento.
corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local5. Se hai copiato pezzi invece di forkare
Un'adozione selettiva — copiare moduli del kit in un'app esistente — non condivide cronologia Git con il kit, quindi git merge non può aiutare. Confronta invece il vecchio SHA sorgente con lo SHA sorgente di destinazione e porta solo le modifiche che toccano la parte che hai adottato.
Esamina i tipi pubblici del modulo, lo schema di persistenza e le migrazioni, il chiamante lato server, la configurazione, i test e la documentazione come un'unica unità — una modifica dentro un pacchetto può richiedere una route o una modifica d'ambiente corrispondente altrove, e copiare un solo helper può lasciare il resto su un contratto obsoleto. Tieni una breve nota di adattamento — quali file del kit hai preso, quali hai saltato, cosa hai cambiato — così il prossimo aggiornamento può ripetere le tue scelte.
Se un aggiornamento rompe qualcosa nella tua copia in esecuzione, segui la guida alla risoluzione dei problemi prima di annullare le tue modifiche.