GitHub-synchronisatie in een browser-IDE: praktische gids

Een browserproject is juist handig omdat het geen map, runtime of installatie nodig heeft. Diezelfde eigenschap is de zwakte. Projecten leven in het browserprofiel, dat door een opruimtool kan worden gewist, met een apparaat verloren kan gaan of achterblijft wanneer iemand van computer wisselt. Een ZIP exporteren maakt een kopie, maar een ZIP is een momentopname zonder geschiedenis of gedeelde remote. GitHub levert de ontbrekende laag: een repository buiten het apparaat, een commitgeschiedenis, een plek om samen te werken en een natuurlijke bron voor CI of deployment. Daardoor verandert de rol van de browser-IDE. Het is geen wegwerpschrijfblok meer; het kan de plek zijn waar een klein project wordt geschreven, beoordeeld en overgedragen. De workflow is vooral nuttig op een Chromebook, een schoolcomputer of een vergrendelde zakelijke laptop waarop Git installeren geen optie is. Ook voor een snel prototype dat later naar een desktop-repository verhuist, werkt het goed. De browser doet de eerste versie; GitHub maakt die duurzaam.

GB Coder biedt drie GitHub-acties: Push, New repo en Pull. Push schrijft het huidige project naar een bestaande repository en branch. New repo maakt een repository aan onder het verbonden GitHub-account en legt het project vast als de eerste inhoud. Pull leest een branch en importeert de tekstbestanden in de editor. Alle verzoeken gaan rechtstreeks van de browser naar api.github.com; geen LadeStack-server zit ertussen om het token vast te houden. Die beperkte scope is bewust. Het paneel vervangt de Git-opdrachtregel niet. Het biedt geen rebase, merge-conflictoplossing, submodules, Git LFS, ondertekende commits, hooks of meerdere remotes. Het toont ook niet de volledige commitgraaf. Die beperkingen doen ertoe bij een complexe repository. Voor het gangbare browserproject — een statische pagina, een React-prototype, een lesvoorbeeld of een kleine utility — dekken de drie acties precies het deel dat buiten het tabblad moet gebeuren.

GitHub-synchronisatie gebruikt een personal access token, geen wachtwoord en geen GB Coder-account. Een klassiek token heeft de repo-scope nodig. Een fine-grained token heeft lees- en schrijftoegang tot Contents nodig en kan tot één repository worden beperkt. De smalste optie is de betere standaard: als het token uitlekt, blijft de schade beperkt tot de projecten die het kan bereiken. Het verbindingsscherm linkt naar de tokenpagina van GitHub en legt beide keuzes uit. Plak het token, kies of je het op het apparaat wilt onthouden en klik op Connect. GB Coder controleert het door het account en de repositorylijst op te halen en toont daarna de ingelogde gebruiker en het resterende API-limiet. Er wordt niets naar de repository geschreven tot een push of het aanmaken van een repository is bevestigd. Behandel het token als een wachtwoord: plak het niet in een issue, chat of screenshot, en trek het op GitHub in wanneer je het niet meer nodig hebt. Een token met een vervaldatum en toegang tot één repository is een redelijke afweging voor deze workflow.

Het tabblad Push vraagt om een repository, branch, commitbericht en één optie: bestanden verwijderen die in het project ontbreken. Voordat er iets de browser verlaat, toont het paneel het aantal bestanden en de totale grootte. Die preview is nuttig omdat de upload geen ruwe dump van editortabbladen is. GB Coder gebruikt dezelfde archiefopbouw als ZIP-export en deployment. Een eenvoudig HTML/CSS/JavaScript-project wordt index.html, style.css, script.js en een README. Een React- of Vue-project wordt een repository met Vite-structuur: index.html, package.json, vite.config.js, .gitignore, een README en de bronbestanden onder src/. Afhankelijkheidsmappen en buildoutput worden niet meegenomen. Het commitbericht is bewerkbaar en staat standaard op 'Update from GB Coder'. De optie om ontbrekende bestanden te verwijderen staat standaard uit; zet hem alleen aan als de repository exact het huidige project moet spiegelen, want hij verwijdert remote bestanden die lokaal niet meer bestaan. Kies voor een eerste push de standaardbranch van de repository, tenzij je bewust een aparte branch wilt.

Een naïeve browsersynchronisatie commit één bestand per keer. Dat levert een rommelige geschiedenis op en laat een repository half bijgewerkt achter als een verzoek halverwege mislukt. GB Coder gebruikt daarom de Git Data API van GitHub: het uploadt blobs, bouwt een tree boven op de huidige tree van de branch, maakt één commit en verplaatst de branchreferentie. Het resultaat is één atomaire commit per push, inclusief eventuele verwijderingen via de bijbehorende optie. De tweede optimalisatie is stiller maar net zo belangrijk. Git identificeert bestandsinhoud met een SHA-1-hash, en de browser kan die lokaal berekenen met WebCrypto. GB Coder vergelijkt de lokale bestanden met de doel-tree voordat er iets wordt geüpload. Ongewijzigde bestanden kosten geen API-aanroepen, en een push zonder wijzigingen geeft 'already up to date' terug in plaats van een lege commit te maken. Dat houdt de geschiedenis leesbaar en houdt het API-budget vrij voor echte wijzigingen. Bij een klein project is het verschil onzichtbaar; bij een project met tientallen bestanden is het het verschil tussen een schone synchronisatie en een trage, lawaaierige.

Het tabblad New repo maakt een repository aan in het verbonden account. Je geeft een naam en optionele beschrijving op, kiest openbaar of privé en beslist of GitHub de repository met een README moet initialiseren. Initialisatie staat standaard aan omdat een lege repository geen branchhoofd heeft waarop de eerste push kan voortbouwen. GB Coder gebruikt die basiscommit, vervangt de README door de bestanden van het project en legt de eerste commit vast. Met initialisatie uit maakt het zelf een rootcommit en de standaardbranchreferentie aan. Na het aanmaken zijn de nieuwe repository en standaardbranch geselecteerd voor de volgende push, dus er is geen tweede configuratieronde. Dit is de kortste weg van een idee naar een privé, geversioneerde repository. Het is nuttig voor een schoolopdracht, een klantdemo die privé moet blijven of een prototype dat een URL nodig heeft voor een CI-service. De repository hoort bij het GitHub-account dat het token bezit, niet bij LadeStack, en kan daarna op GitHub worden beheerd, overgedragen of verwijderd.

Pull is de terugreis. Voer een repository-URL of een eigenaar/naam-paar in, kies een branch en GB Coder leest de branch-tree. Het importeert tekstbestanden die een editor zinvol kan openen: broncode, JSON, Markdown, configuratie en SVG, onder andere. Het slaat de mappen node_modules, dist, build, .git, .next en coverage over. Een pull is ook beperkt tot 200 bestanden en 512 KB per bestand; als de branch een van beide limieten overschrijdt, meldt het paneel hoeveel bestanden zijn weggelaten in plaats van ze stil te laten vallen. Regeleinden worden genormaliseerd, zodat een bestand dat op Windows is gemaakt niet op elke regel lijkt te veranderen. De geïmporteerde bestanden overschrijven het project niet meteen. Ze gaan door dezelfde beoordelings- en toepassingsflow als een ZIP-import, dus je kunt de gedetecteerde structuur bekijken voordat je de wijziging doorvoert en die daarna ongedaan maken. Pull is daarom handig om op een ander apparaat verder te werken, een repository te bekijken voordat je gaat bewerken, of een project te herstellen nadat browseropslag is gewist. Het is een import, geen merge; als het huidige project en de branch uit elkaar zijn gelopen, controleer het resultaat dan zorgvuldig.

De belangrijkste veiligheidseigenschap is wat er gebeurt wanneer de remote branch verandert terwijl je aan het bewerken bent. GB Coder werkt de branchreferentie bij met force uitgeschakeld. Als iemand anders intussen heeft gepusht, weigert GitHub de update en meldt het paneel een conflict in plaats van diens werk stil te overschrijven. De oplossing is bewust handmatig: haal de nieuwste branch in een project, controleer de bestanden en push opnieuw — of stap over op een desktop-Git-client voor een echte merge. Andere fouten worden apart gemeld zodat het bericht bruikbaar is. Een verlopen token geeft een authenticatiefout en een verzoek om opnieuw te verbinden. Een rate limit toont wanneer het GitHub-quotum reset; de API staat 5.000 verzoeken per uur toe voor geauthenticeerde gebruikers, en een pull verbruikt één verzoek per bestand. Een ontbrekende repository of branch geeft een not-found-fout. Verzoeken verlopen na 60 seconden en een langdurige bewerking kan vanuit het paneel worden geannuleerd. Die details zijn niet glamoureus, maar ze maken het verschil tussen een synchronisatietool die je kunt vertrouwen en een die op onduidelijke manieren faalt.

Tokens zijn waardevolle inloggegevens. Een GitHub-token met schrijftoegang kan elke repository wijzigen die het kan bereiken. GB Coder bewaart een geplakt token standaard in een map binnen de modulescope, wat betekent dat het verdwijnt wanneer het tabblad sluit en nooit naar localStorage wordt geschreven. De optie 'Remember on this device' is een expliciete opt-in. Wanneer die aan staat en de pagina een secure context is, wordt het token met AES-GCM verzegeld onder een willekeurige sleutel per installatie voordat het wordt opgeslagen. Dat beschermt tegen een leesbaar token in een back-up van het browserprofiel, een gesynchroniseerd profiel, een gedeelde machine, een screenshot van ontwikkelaarstools of een supportbundel. Het beschermt niet tegen een script dat op dezelfde origin kan draaien, want zo'n script kan dezelfde opslagmodule aanroepen. Geen enkele browser-only oplossing lost dat volledig op. De praktische maatregelen zijn daarom scope, vervaldatum en intrekking: gebruik een fine-grained token dat beperkt is tot de repository die je nodig hebt, stel een vervaldatum in en verwijder het token op GitHub wanneer het werk klaar is. GitHub-verkeer gaat rechtstreeks van de browser naar api.github.com; LadeStack hoeft de inloggegevens niet te bewaren. Browseropslag is nog steeds geen back-up, dus een repository is ook een verstandige kopie buiten het apparaat.

GitHub-synchronisatie is voldoende voor een groot deel van de browserprojecten: een statische site, een React- of Vue-prototype, een klasoefening, een kleine interne tool of een demo die een remote en een deploymentbron nodig heeft. Het past bij een solo-ontwikkelaar die versiebeheer wil zonder Git te installeren, bij een docent die een reproduceerbare overdracht nodig heeft en bij iedereen die op een machine zonder terminal werkt. Het is niet voldoende voor een monorepo met submodules, een repository die van Git LFS afhankelijk is, een team dat ondertekende commits of een gedetailleerde beoordeling van de commitgeschiedenis nodig heeft, of een releaseproces met hooks en meerdere remotes. Dat zijn desktop-Git-taken, en doen alsof dat niet zo is, zou de browserworkflow slechter maken. Het nuttige patroon is hybride. Begin in de browser omdat de eerste preview direct is. Push wanneer het project een vorm heeft die het waard is om te bewaren. Open dezelfde repository op de desktop wanneer het werk native tooling, een diepere debugger of een volledige Git-workflow nodig heeft. Haal wijzigingen via GitHub terug wanneer je naar de browser terugkeert. De bestanden zijn gewone bronbestanden, dus de overdracht is versiebeheer en geen migratie. Om de browserhelft uit te proberen, open je het Projects Dashboard op /app/projects, maak je een project aan, open je GitHub sync en push je een eerste commit. De volledige installatie en functiereferentie staan in de documentatie.