Guide de synchronisation GitHub dans un IDE de navigateur

Un projet dans le navigateur est pratique précisément parce qu'il n'a besoin ni de dossier, ni de runtime, ni d'installation. Cette même propriété est sa faiblesse. Les projets vivent dans le profil du navigateur, qui peut être effacé par un outil de nettoyage, perdu avec un appareil ou laissé derrière soi lorsqu'on change d'ordinateur. Exporter un ZIP crée une copie, mais un ZIP est un instantané sans historique ni remote partagé. GitHub apporte la couche manquante : un dépôt hors appareil, un historique de commits, un espace de collaboration et une source naturelle pour la CI ou le déploiement. Cela change le rôle de l'IDE navigateur. Ce n'est plus un brouillon jetable ; il peut être l'endroit où un petit projet est écrit, relu et transmis. Le workflow est particulièrement utile sur un Chromebook, une machine de salle de classe ou un ordinateur portable d'entreprise verrouillé où installer Git n'est pas possible. Il convient aussi à un prototype rapide qui pourra ensuite rejoindre un dépôt de bureau. Le navigateur prend en charge la première version ; GitHub la rend durable.

GB Coder expose trois actions GitHub : Push, New repo et Pull. Push écrit le projet courant dans un dépôt et une branche existants. New repo crée un dépôt sous le compte GitHub connecté et y enregistre le projet comme premier contenu. Pull lit une branche et importe ses fichiers texte dans l'éditeur. Toutes les requêtes vont directement du navigateur à api.github.com ; aucun serveur LadeStack ne s'interpose pour conserver le jeton. Ce périmètre étroit est volontaire. Le panneau ne remplace pas la ligne de commande Git. Il ne propose ni rebase, ni résolution de conflit de merge, ni sous-modules, ni Git LFS, ni commits signés, ni hooks, ni remotes multiples. Il n'affiche pas non plus le graphe complet des commits. Ces limites comptent sur un dépôt complexe. Pour le projet courant dans le navigateur — une page statique, un prototype React, un exemple pédagogique ou un petit utilitaire —, les trois opérations couvrent la partie qui doit réellement se passer hors de l'onglet.

La synchronisation GitHub utilise un jeton d'accès personnel, pas un mot de passe ni un compte GB Coder. Un jeton classique a besoin de la portée repo. Un jeton fine-grained a besoin d'un accès en lecture et écriture à Contents, et peut être limité à un seul dépôt. L'option la plus étroite est le meilleur choix par défaut : si le jeton fuit, les dégâts restent limités aux projets qu'il peut atteindre. L'écran de connexion renvoie à la page de jetons de GitHub et explique les deux choix. Collez le jeton, choisissez de le mémoriser ou non sur l'appareil, puis cliquez sur Connect. GB Coder le vérifie en récupérant le compte et la liste des dépôts, puis affiche l'identifiant connecté et la limite d'API restante. Rien n'est écrit dans le dépôt tant qu'un push ou la création d'un dépôt n'est pas confirmé. Traitez le jeton comme un mot de passe : ne le collez pas dans une issue, un chat ou une capture d'écran, et révoquez-le sur GitHub lorsqu'il n'est plus utile. Un jeton avec une date d'expiration et un accès à un seul dépôt est un compromis raisonnable pour ce workflow.

L'onglet Push demande un dépôt, une branche, un message de commit et une option : supprimer les fichiers absents du projet. Avant que quoi que ce soit ne quitte le navigateur, le panneau affiche le nombre de fichiers et la taille totale. Cet aperçu est utile car l'envoi n'est pas un simple vidage des onglets de l'éditeur. GB Coder utilise le même constructeur d'archive que l'export ZIP et le déploiement. Un projet HTML/CSS/JavaScript simple devient index.html, style.css, script.js et un README. Un projet React ou Vue devient un dépôt de structure Vite avec index.html, package.json, vite.config.js, .gitignore, un README et les fichiers source sous src/. Les dossiers de dépendances et la sortie de build ne sont pas inclus. Le message de commit est modifiable et vaut par défaut 'Update from GB Coder'. L'option de suppression des fichiers absents est désactivée par défaut ; activez-la uniquement lorsque le dépôt doit refléter exactement le projet courant, car elle supprime les fichiers distants qui n'existent plus en local. Pour un premier push, choisissez la branche par défaut du dépôt, sauf si vous voulez délibérément une branche séparée.

Une synchronisation naïve depuis le navigateur valide un fichier à la fois. Cela produit un historique bruyant et laisse un dépôt à moitié mis à jour si une requête échoue en cours de route. GB Coder utilise plutôt l'API Git Data de GitHub : elle envoie des blobs, construit un tree au-dessus du tree courant de la branche, crée un commit et déplace la référence de branche. Le résultat est un seul commit atomique par push, y compris les suppressions demandées par l'option correspondante. La seconde optimisation est plus discrète mais tout aussi importante. Git identifie le contenu d'un fichier par un hash SHA-1, et le navigateur peut calculer ce hash localement avec WebCrypto. GB Coder compare les fichiers locaux au tree cible avant l'envoi. Les fichiers inchangés ne coûtent aucun appel d'API, et un push sans changement renvoie 'already up to date' au lieu de créer un commit vide. Cela garde l'historique lisible et réserve le budget d'API aux vrais changements. Sur un petit projet, la différence est invisible ; sur un projet de plusieurs dizaines de fichiers, c'est la différence entre une synchronisation propre et une synchronisation lente et bruyante.

L'onglet New repo crée un dépôt dans le compte connecté. Vous indiquez un nom et une description facultative, choisissez public ou privé, et décidez si GitHub doit initialiser le dépôt avec un README. L'initialisation est active par défaut car un dépôt vide n'a pas de tête de branche sur laquelle construire le premier push. GB Coder utilise ce commit initial, remplace le README par les fichiers du projet et enregistre le commit initial. Si l'initialisation est désactivée, il crée lui-même un commit racine et la référence de branche par défaut. Après la création, le nouveau dépôt et la branche par défaut sont sélectionnés pour le push suivant, donc il n'y a pas de seconde configuration. C'est le chemin le plus court d'une idée à un dépôt privé et versionné. C'est utile pour un devoir de classe, une démo client qui doit rester privée ou un prototype qui a besoin d'une URL pour un service de CI. Le dépôt appartient au compte GitHub propriétaire du jeton, pas à LadeStack, et peut ensuite être géré, transféré ou supprimé depuis GitHub.

Pull est le trajet retour. Saisissez l'URL d'un dépôt ou un couple propriétaire/nom, choisissez une branche, et GB Coder lit le tree de la branche. Il importe les fichiers texte qu'un éditeur peut ouvrir utilement : code source, JSON, Markdown, configuration et SVG, entre autres. Il ignore les dossiers node_modules, dist, build, .git, .next et coverage. Il limite aussi un pull à 200 fichiers et 512 Ko par fichier ; si la branche dépasse l'une de ces limites, le panneau indique combien de fichiers ont été écartés au lieu de les abandonner silencieusement. Les fins de ligne sont normalisées pour qu'un fichier créé sous Windows ne semble pas changer à chaque ligne. Les fichiers importés n'écrasent pas immédiatement le projet. Ils passent par le même flux de revue et d'application qu'un import ZIP, ce qui permet d'inspecter la structure détectée avant de valider la modification et de l'annuler ensuite. Pull est donc un bon moyen de continuer le travail sur un autre appareil, d'inspecter un dépôt avant de l'éditer ou de récupérer un projet après l'effacement du stockage du navigateur. C'est un import, pas un merge ; si le projet courant et la branche ont divergé, examinez le résultat avec attention.

La propriété de sécurité la plus importante est ce qui se passe lorsque la branche distante avance pendant que vous éditez. GB Coder met à jour la référence de branche avec force désactivé. Si quelqu'un d'autre a poussé entre-temps, GitHub rejette la mise à jour et le panneau signale un conflit au lieu d'écraser silencieusement son travail. La résolution est volontairement manuelle : tirez la dernière version de la branche dans un projet, vérifiez les fichiers et poussez à nouveau — ou passez à un client Git de bureau pour un vrai merge. Les autres échecs sont distingués pour que le message soit exploitable. Un jeton expiré produit une erreur d'authentification et une demande de reconnexion. Une limite de débit indique quand le quota GitHub se réinitialise ; l'API autorise 5 000 requêtes par heure pour les utilisateurs authentifiés, et un pull consomme une requête par fichier. Un dépôt ou une branche absent produit une erreur introuvable. Les requêtes expirent après 60 secondes, et une opération longue peut être annulée depuis le panneau. Ces détails ne sont pas spectaculaires, mais ils font la différence entre un outil de synchronisation fiable et un outil qui échoue de manière ambiguë.

Les jetons sont des identifiants de grande valeur. Un jeton GitHub avec accès en écriture peut modifier chaque dépôt qu'il peut atteindre. GB Coder conserve un jeton collé dans une map de portée module par défaut, ce qui signifie qu'il disparaît à la fermeture de l'onglet et n'est jamais écrit dans localStorage. L'option 'Remember on this device' est un opt-in explicite. Lorsqu'elle est activée et que la page est en contexte sécurisé, le jeton est scellé avec AES-GCM sous une clé aléatoire par installation avant d'être stocké. Cela protège contre un jeton lisible dans une sauvegarde de profil navigateur, un profil synchronisé, une machine partagée, une capture d'écran des outils de développement ou un bundle de support. Cela ne protège pas contre un script capable de s'exécuter sur la même origine, car un tel script peut appeler le même module de stockage. Aucune conception purement navigateur ne peut résoudre complètement ce problème. Les contrôles pratiques sont donc la portée, l'expiration et la révocation : utilisez un jeton fine-grained limité au dépôt nécessaire, fixez une expiration et supprimez le jeton sur GitHub lorsque le travail est terminé. Le trafic GitHub va directement du navigateur à api.github.com ; LadeStack n'a pas besoin de conserver l'identifiant. Le stockage du navigateur n'est toujours pas une sauvegarde, donc un dépôt constitue aussi une copie raisonnable hors appareil.

La synchronisation GitHub suffit à une grande partie des projets navigateur : un site statique, un prototype React ou Vue, un exercice de classe, un petit outil interne ou une démo qui a besoin d'un remote et d'une source de déploiement. Elle convient à un développeur solo qui veut du contrôle de version sans installer Git, à un enseignant qui a besoin d'une transmission reproductible et à toute personne travaillant sur une machine sans terminal. Elle ne suffit pas pour un monorepo avec sous-modules, un dépôt qui dépend de Git LFS, une équipe qui exige des commits signés ou une revue détaillée de l'historique, ni un processus de release fondé sur des hooks et plusieurs remotes. Ce sont des tâches Git de bureau, et prétendre le contraire dégraderait le workflow navigateur. Le modèle utile est hybride. Commencez dans le navigateur car le premier aperçu est immédiat. Poussez lorsque le projet a une forme qui mérite d'être conservée. Ouvrez le même dépôt sur le bureau lorsque le travail exige des outils natifs, un débogueur plus profond ou un workflow Git complet. Récupérez les changements via GitHub lorsque vous revenez au navigateur. Les fichiers sont des fichiers source ordinaires : la transition relève du contrôle de version, pas d'une migration. Pour essayer la moitié navigateur, ouvrez le Projects Dashboard sur /app/projects, créez un projet, ouvrez GitHub sync et poussez un premier commit. La configuration complète et la référence des fonctionnalités se trouvent dans la documentation.