GitHub Sync in a Browser IDE: A Practical Guide

A browser project is convenient precisely because it needs no folder, no runtime, and no installation. The same property is its weakness. Projects live in the browser profile, which can be cleared by a cleanup tool, lost with a device, or left behind when someone switches computers. Exporting a ZIP creates a copy, but a ZIP is a snapshot without history or a shared remote. GitHub supplies the missing layer: an off-device repository, a commit history, a place to collaborate, and a natural source for CI or deployment. That changes the role of the browser IDE. It is no longer a disposable scratchpad; it can be the place where a small project is written, reviewed, and handed off. The workflow is especially useful on a Chromebook, a school lab machine, or a locked-down corporate laptop where installing Git is not an option. It is also useful for a quick prototype that may later move to a desktop repository. The browser handles the first draft; GitHub makes it durable.

GB Coder exposes three GitHub actions: Push, New repo, and Pull. Push writes the current project into an existing repository and branch. New repo creates a repository under the connected GitHub account and commits the project as its first content. Pull reads a branch and imports its text files into the editor. All requests go directly from the browser to api.github.com; no LadeStack server sits in the middle holding the token. That narrow scope is deliberate. The panel is not a replacement for the Git command line. It does not provide rebase, merge conflict resolution, submodules, Git LFS, signed commits, hooks, or multiple remotes. It does not show the full commit graph. Those limitations matter on a complex repository. For the common browser project—a static page, a React prototype, a teaching example, or a small utility—the three operations cover the part that actually needs to happen outside the tab.

GitHub sync uses a personal access token, not a password and not a GB Coder account. A classic token needs the repo scope. A fine-grained token needs read and write access to Contents, and it can be limited to a single repository. The narrower option is the better default: if the token leaks, the damage is confined to the projects it can reach. The connect screen links to GitHub's token page and explains both choices. Paste the token, choose whether to remember it on the device, and press Connect. GB Coder verifies it by fetching the account and the repository list, then shows the signed-in login and the remaining API rate limit. Nothing is written to the repository until a push or a new-repo action is confirmed. Treat the token like a password: do not paste it into an issue, a chat, or a screenshot, and revoke it on GitHub when it is no longer needed. A token with an expiry date and access to one repository is a reasonable trade-off for this workflow.

The Push tab asks for a repository, a branch, a commit message, and one optional choice: delete files that are missing from the project. Before anything leaves the browser, the panel shows the file count and total size. That preview is useful because the upload is not a raw dump of editor tabs. GB Coder uses the same archive builder as ZIP export and deployment. A plain HTML/CSS/JavaScript project becomes index.html, style.css, script.js, and a README. A React or Vue project becomes a Vite-shaped repository with index.html, package.json, vite.config.js, .gitignore, a README, and the source files under src/. Dependency folders and build output are not included. The commit message is editable and defaults to 'Update from GB Coder'. The delete-missing option is off by default; turn it on only when the repository should mirror the current project exactly, because it removes remote files that no longer exist locally. For a first push, choose the repository's default branch unless you deliberately want a separate branch.

A naive browser sync commits one file at a time. That produces noisy history and leaves a repository half-updated if a request fails in the middle. GB Coder uses GitHub's Git Data API instead: it uploads blobs, builds a tree on top of the branch's current tree, creates one commit, and moves the branch reference. The result is a single atomic commit per push, including any deletions requested by the delete-missing option. The second optimization is quieter but just as important. Git identifies file content by a SHA-1 hash, and the browser can compute that hash locally with WebCrypto. GB Coder compares the local files with the target tree before uploading. Unchanged files cost no API calls, and a push where nothing changed returns 'already up to date' instead of creating an empty commit. That keeps history readable and preserves the API budget for real changes. On a small project the difference is invisible; on a project with dozens of files it is the difference between a clean sync and a slow, noisy one.

The New repo tab creates a repository in the connected account. You provide a name and an optional description, choose public or private, and decide whether GitHub should initialize the repository with a README. Initialization is on by default because an empty repository has no branch head for the first push to build on. GB Coder uses that seed commit, replaces the README with the project's own files, and records the initial commit. With initialization turned off, it creates a root commit and the default branch reference itself. After creation, the new repository and default branch are selected for the next push, so there is no second round of setup. This is the shortest path from an idea to a private, versioned repository. It is useful for a classroom assignment, a client demo that should stay private, or a prototype that needs a URL for a CI service. The repository belongs to the GitHub account that owns the token, not to LadeStack, and it can be managed, transferred, or deleted from GitHub afterward.

Pull is the return trip. Enter a repository URL or an owner/name pair, choose a branch, and GB Coder reads the branch tree. It imports text files that an editor can meaningfully open: source files, JSON, Markdown, configuration, and SVG, among others. It skips node_modules, dist, build, .git, .next, and coverage directories. It also caps a pull at 200 files and 512 KB per file; if the branch exceeds either limit, the panel says how many files were left out instead of silently dropping them. Line endings are normalized so a Windows-authored file does not appear to change every line. The imported files do not overwrite the project immediately. They pass through the same review-and-apply flow as a ZIP import, which means you can inspect the detected structure before committing to the change and can undo it afterward. Pull is therefore a good way to continue work on another device, inspect a repository before editing, or recover a project after browser storage was cleared. It is an import, not a merge; if the current project and the branch have diverged, review the result carefully.

The most important safety property is what happens when the remote branch moves while you are editing. GB Coder updates the branch reference with force disabled. If someone else pushed in the meantime, GitHub rejects the update and the panel reports a conflict rather than silently discarding their work. The resolution is deliberately manual: pull the latest branch into a project, review the files, and push again—or move to a desktop Git client for a real merge. Other failures are separated so the message can be acted on. A dead token produces an authentication error and a request to reconnect. A rate limit shows when the GitHub quota resets; the API allows 5,000 requests per hour for authenticated users, and a pull spends one request per file. A missing repository or branch produces a not-found error. Requests time out after 60 seconds, and a long operation can be cancelled from the panel. These details are not glamorous, but they are the difference between a sync tool you can trust and one that fails in ambiguous ways.

Tokens are high-value credentials. A GitHub token with write access can change every repository it can reach. GB Coder keeps a pasted token in a module-scoped map by default, which means it disappears when the tab is closed and is never written to localStorage. The 'Remember on this device' option is an explicit opt-in. When it is enabled and the page is a secure context, the token is sealed with AES-GCM under a random per-install key before being stored. That protects against a readable token in a browser-profile backup, a synced profile, a shared machine, a screenshot of developer tools, or a support bundle. It does not protect against a script that can run on the same origin, because such a script can call the same storage module. No browser-only design can fully solve that. The practical controls are therefore scope, expiry, and revocation: use a fine-grained token limited to the repository you need, set an expiry, and delete the token on GitHub when the work is done. GitHub traffic goes directly from the browser to api.github.com; LadeStack does not need to hold the credential. Browser storage is still not a backup, so a repository is also a sensible off-device copy.

GitHub sync is enough for a large share of browser projects: a static site, a React or Vue prototype, a classroom exercise, a small internal tool, or a demo that needs a remote and a deployment source. It fits a solo developer who wants version control without installing Git, a teacher who needs a reproducible handoff, and anyone working on a machine where a terminal is unavailable. It is not enough for a monorepo with submodules, a repository that depends on Git LFS, a team that needs signed commits or a detailed review of commit history, or a release process built on hooks and multiple remotes. Those are desktop Git jobs, and pretending otherwise would make the browser workflow worse. The useful pattern is hybrid. Start in the browser because the first preview is immediate. Push when the project has a shape worth keeping. Open the same repository on the desktop when the work needs native tooling, a deeper debugger, or a full Git workflow. Pull changes back through GitHub when you return to the browser. The files are ordinary source files, so the handoff is version control rather than migration. To try the browser half, open the Projects Dashboard at /app/projects, create a project, open GitHub sync, and push a first commit. The full setup and feature reference is in the docs.