Mettez à jour votre copie quand le kit s'améliore

1. Notez ce dont vous êtes parti

Traitez une mise à jour comme un petit projet, pas comme un collage : vous comparez la révision du kit que vous avez avec la plus récente, reportez les changements et testez sur une branche avant de déployer. Cela fonctionne que votre projet soit un fork d'un dépôt du kit — une copie que GitHub garde connectée à la source — ou du code que vous avez copié dans votre propre app.

Avant toute chose, écrivez une note dans votre projet avec trois éléments : le commit du kit dont vous êtes parti — le SHA, le code court de Git qui identifie une version exacte — le dépôt que vous avez reçu (supastack-web, supastack-mobile, supastack-desktop ou le monorepo All Platforms), et les changements que vous avez déjà faits vous-même.

Les dépôts du kit et le monorepo ont des historiques différents, donc ne fusionnez jamais une branche de l'un dans un fork de l'autre. Si vous n'avez jamais noté de SHA de départ, trouvez la version partagée la plus proche avec git merge-base dans un fork, ou identifiez les derniers fichiers et tests que vous avez copiés dans une adoption sélective — et relisez un diff plus large quand la base exacte est incertaine.

2. Récupérez et fusionnez la nouvelle révision

Exécutez les commandes ci-dessous dans un terminal à l'intérieur de votre dossier de projet, avec votre travail enregistré et committé — un arbre de travail propre, pour que rien à moitié fait ne se mélange à la fusion. Les mots entre chevrons sont des gabarits à remplacer : substituez vos propres valeurs à la place de tout le <thing>. L'adresse GitHub montrée est un placeholder ; utilisez l'adresse du dépôt que vous avez forké.

Ce que font les lignes : git remote add apprend à votre copie une seconde adresse nommée kit-upstream — le dépôt du kit — et git fetch télécharge son état le plus récent sans toucher vos fichiers. git switch -c crée une branche d'upgrade séparée pour que votre branche principale reste intacte pendant que vous relisez. git log liste les commits que vous allez prendre et git diff --stat résume quels fichiers ont changé ; lisez le diff complet pour les modules que vous utilisez, pas seulement les titres des commits. git merge amène le nouveau code dans la branche d'upgrade.

Si Git signale que le remote kit-upstream existe déjà, sautez la ligne remote add et continuez avec git fetch. <previous-kit-sha> est le SHA de départ que vous avez noté à l'étape 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/main

3. Résolvez les conflits sans perdre votre travail

Un conflit signifie que les deux côtés ont changé les mêmes lignes : le kit a avancé et vous avez personnalisé le même endroit. Git met la fusion en pause et marque le fichier — il vous demande de choisir, il ne signale pas de dégât.

Ouvrez chaque fichier marqué dans votre éditeur et décidez ligne par ligne : gardez le texte, les noms et les réglages propres à votre produit, et prenez les corrections et changements structurels du kit. Ne résolvez jamais un conflit en remplaçant un fichier que vous avez personnalisé par toute la nouvelle version du kit — cela efface votre travail. Résolvez dans la branche d'upgrade et exécutez les tests de chaque zone résolue avant de continuer.

Si la fusion tourne mal, git merge --abort ramène la branche à son état d'avant la fusion. Rien dans ce flux ne change votre branche principale ni votre déploiement tant que vous n'avez pas fusionné la branche d'upgrade vous-même.

4. Mettez à jour les données et déployez dans le bon ordre

Les nouvelles révisions du kit peuvent changer la base de données. Lisez les nouveaux fichiers dans packages/db/drizzle/ — le dossier des migrations — et sauvegardez les données de production avant d'appliquer les migrations ; testez-les d'abord contre une copie jetable. Déployez les changements de schéma compatibles avant le code qui en a besoin : si une migration supprime ou remodèle des données, revenir en arrière sur le code de l'app seul ne peut pas restaurer l'ancien schéma.

Comparez le nouveau .env.example avec vos propres réglages et ajoutez les valeurs nouvellement requises dans votre tableau de bord d'hébergement. Les fichiers .env portent des secrets et ne sont jamais committés dans Git — vous les recréez à la main sur chaque machine et chaque déploiement, et ils restent hors des valeurs NEXT_PUBLIC_ et EXPO_PUBLIC_.

Avant de déployer, exécutez les propres portes de vérification du kit. Dans le monorepo All Platforms, corepack pnpm check:local exécute le lint, le typecheck, les tests unitaires et un contrôle de format sans identifiants payants ; corepack pnpm verify:local ajoute le build de production et les suites de tests navigateur. Dans un fork mono-surface, exécutez les propres commandes de test et de build de ce dépôt. Faites ensuite une passe de smoke en staging : connectez-vous, essayez un second espace de travail, et parcourez le parcours utilisateur principal de votre produit.

Quand tout passe, notez le SHA cible accepté et les conflits que vous avez résolus — cette note est la base de départ de la prochaine mise à jour.

corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local

5. Si vous avez copié des morceaux au lieu de forker

Une adoption sélective — copier des modules du kit dans une app existante — ne partage aucun historique Git avec le kit, donc git merge ne peut pas aider. Comparez plutôt l'ancien SHA source avec le SHA source cible, et ne portez que les changements qui touchent votre partie adoptée.

Relisez les types publics du module, le schéma de persistance et les migrations, l'appelant serveur, la configuration, les tests et les docs comme un tout — un changement dans un package peut exiger une route ou un changement d'environnement correspondant ailleurs, et copier un seul helper peut laisser le reste sur un contrat obsolète. Gardez une courte note d'adaptation — quels fichiers du kit vous avez pris, lesquels vous avez sautés, ce que vous avez changé — pour que la prochaine mise à jour puisse rejouer vos choix.

Si une mise à jour casse quelque chose dans votre copie en cours, parcourez le guide de dépannage avant d'annuler vos propres changements.

• Corrigez un problème après une mise à jour