Sincronización con GitHub en un IDE de navegador

Un proyecto en el navegador es cómodo precisamente porque no necesita carpeta, entorno de ejecución ni instalación. Esa misma propiedad es su debilidad. Los proyectos viven en el perfil del navegador, que puede borrar una herramienta de limpieza, perderse con un dispositivo o quedarse atrás cuando alguien cambia de computadora. Exportar un ZIP crea una copia, pero un ZIP es una instantánea sin historial ni remoto compartido. GitHub aporta la capa que falta: un repositorio fuera del dispositivo, un historial de commits, un lugar para colaborar y una fuente natural para CI o despliegue. Eso cambia el papel del IDE de navegador. Ya no es un bloc de notas desechable; puede ser el lugar donde un proyecto pequeño se escribe, se revisa y se entrega. El flujo resulta especialmente útil en un Chromebook, una máquina de laboratorio escolar o un portátil corporativo bloqueado donde instalar Git no es una opción. También sirve para un prototipo rápido que más adelante puede pasar a un repositorio de escritorio. El navegador se encarga del primer borrador; GitHub lo hace duradero.

GB Coder ofrece tres acciones de GitHub: Push, New repo y Pull. Push escribe el proyecto actual en un repositorio y una rama existentes. New repo crea un repositorio en la cuenta de GitHub conectada y confirma el proyecto como su primer contenido. Pull lee una rama e importa sus archivos de texto al editor. Todas las solicitudes van directamente del navegador a api.github.com; ningún servidor de LadeStack se interpone para guardar el token. Ese alcance limitado es intencional. El panel no sustituye la línea de comandos de Git. No ofrece rebase, resolución de conflictos de merge, submódulos, Git LFS, commits firmados, hooks ni múltiples remotos. Tampoco muestra el grafo completo de commits. Esas limitaciones importan en un repositorio complejo. Para el proyecto habitual en el navegador —una página estática, un prototipo de React, un ejemplo didáctico o una utilidad pequeña—, las tres operaciones cubren la parte que realmente debe ocurrir fuera de la pestaña.

La sincronización con GitHub usa un token de acceso personal, no una contraseña ni una cuenta de GB Coder. Un token clásico necesita el alcance repo. Un token fine-grained necesita acceso de lectura y escritura a Contents, y puede limitarse a un solo repositorio. La opción más estrecha es el mejor valor predeterminado: si el token se filtra, el daño queda limitado a los proyectos que puede alcanzar. La pantalla de conexión enlaza a la página de tokens de GitHub y explica ambas opciones. Pega el token, elige si quieres recordarlo en el dispositivo y pulsa Connect. GB Coder lo verifica obteniendo la cuenta y la lista de repositorios, y luego muestra el usuario conectado y el límite de la API restante. No se escribe nada en el repositorio hasta que se confirma un push o la creación de un repositorio. Trata el token como una contraseña: no lo pegues en un issue, un chat o una captura de pantalla, y revócalo en GitHub cuando ya no lo necesites. Un token con fecha de caducidad y acceso a un solo repositorio es un equilibrio razonable para este flujo.

La pestaña Push pide un repositorio, una rama, un mensaje de commit y una opción: eliminar los archivos que faltan en el proyecto. Antes de que algo salga del navegador, el panel muestra la cantidad de archivos y el tamaño total. Esa vista previa es útil porque la carga no es un volcado directo de las pestañas del editor. GB Coder usa el mismo generador de archivos que la exportación ZIP y el despliegue. Un proyecto simple de HTML/CSS/JavaScript se convierte en index.html, style.css, script.js y un README. Un proyecto de React o Vue se convierte en un repositorio con estructura de Vite: index.html, package.json, vite.config.js, .gitignore, un README y los archivos fuente bajo src/. Las carpetas de dependencias y la salida de compilación no se incluyen. El mensaje de commit es editable y por defecto es 'Update from GB Coder'. La opción de eliminar archivos ausentes está desactivada por defecto; actívala solo cuando el repositorio deba reflejar exactamente el proyecto actual, porque borra archivos remotos que ya no existen en local. Para el primer push, elige la rama predeterminada del repositorio salvo que quieras deliberadamente una rama separada.

Una sincronización ingenua desde el navegador confirma un archivo a la vez. Eso produce un historial ruidoso y deja el repositorio a medio actualizar si una solicitud falla en el medio. GB Coder usa la API Git Data de GitHub: sube blobs, construye un árbol sobre el árbol actual de la rama, crea un commit y mueve la referencia de la rama. El resultado es un único commit atómico por push, incluidas las eliminaciones solicitadas por la opción correspondiente. La segunda optimización es más silenciosa pero igual de importante. Git identifica el contenido de un archivo mediante un hash SHA-1, y el navegador puede calcularlo localmente con WebCrypto. GB Coder compara los archivos locales con el árbol destino antes de subirlos. Los archivos sin cambios no gastan llamadas a la API, y un push sin cambios devuelve 'already up to date' en lugar de crear un commit vacío. Eso mantiene el historial legible y reserva el presupuesto de la API para cambios reales. En un proyecto pequeño la diferencia es invisible; en uno con decenas de archivos es la diferencia entre una sincronización limpia y otra lenta y ruidosa.

La pestaña New repo crea un repositorio en la cuenta conectada. Indicas un nombre y una descripción opcional, eliges público o privado y decides si GitHub debe inicializar el repositorio con un README. La inicialización está activada por defecto porque un repositorio vacío no tiene una cabeza de rama sobre la que construir el primer push. GB Coder usa ese commit inicial, reemplaza el README con los archivos del proyecto y registra el commit inicial. Con la inicialización desactivada, crea un commit raíz y la referencia de la rama predeterminada por su cuenta. Después de la creación, el nuevo repositorio y la rama predeterminada quedan seleccionados para el siguiente push, así que no hay una segunda ronda de configuración. Es el camino más corto de una idea a un repositorio privado y versionado. Resulta útil para una tarea de clase, una demo para un cliente que debe permanecer privada o un prototipo que necesita una URL para un servicio de CI. El repositorio pertenece a la cuenta de GitHub dueña del token, no a LadeStack, y puede gestionarse, transferirse o eliminarse desde GitHub después.

Pull es el viaje de vuelta. Introduce la URL de un repositorio o un par propietario/nombre, elige una rama y GB Coder lee el árbol de la rama. Importa archivos de texto que un editor puede abrir de forma útil: código fuente, JSON, Markdown, configuración y SVG, entre otros. Omite los directorios node_modules, dist, build, .git, .next y coverage. También limita un pull a 200 archivos y 512 KB por archivo; si la rama supera cualquiera de los dos límites, el panel indica cuántos archivos quedaron fuera en lugar de descartarlos en silencio. Los finales de línea se normalizan para que un archivo creado en Windows no parezca cambiar en todas las líneas. Los archivos importados no sobrescriben el proyecto de inmediato. Pasan por el mismo flujo de revisión y aplicación que una importación ZIP, así que puedes inspeccionar la estructura detectada antes de confirmar el cambio y deshacerlo después. Pull es, por tanto, una buena forma de continuar el trabajo en otro dispositivo, inspeccionar un repositorio antes de editarlo o recuperar un proyecto después de que se borrara el almacenamiento del navegador. Es una importación, no un merge; si el proyecto actual y la rama han divergido, revisa el resultado con cuidado.

La propiedad de seguridad más importante es qué ocurre cuando la rama remota avanza mientras editas. GB Coder actualiza la referencia de la rama con force desactivado. Si otra persona hizo push mientras tanto, GitHub rechaza la actualización y el panel informa un conflicto en lugar de descartar su trabajo en silencio. La resolución es deliberadamente manual: trae la última versión de la rama a un proyecto, revisa los archivos y vuelve a hacer push, o pasa a un cliente Git de escritorio para un merge real. Otros fallos se separan para que el mensaje permita actuar. Un token caducado produce un error de autenticación y una petición de reconexión. Un límite de velocidad muestra cuándo se restablece la cuota de GitHub; la API permite 5.000 solicitudes por hora para usuarios autenticados, y un pull gasta una solicitud por archivo. Un repositorio o una rama inexistentes producen un error de no encontrado. Las solicitudes tienen un tiempo de espera de 60 segundos y una operación larga puede cancelarse desde el panel. Estos detalles no son glamorosos, pero marcan la diferencia entre una herramienta de sincronización fiable y otra que falla de forma ambigua.

Los tokens son credenciales de alto valor. Un token de GitHub con acceso de escritura puede modificar todos los repositorios que alcance. GB Coder guarda un token pegado en un mapa dentro del ámbito del módulo por defecto, lo que significa que desaparece al cerrar la pestaña y nunca se escribe en localStorage. La opción 'Recordar en este dispositivo' es un opt-in explícito. Cuando se activa y la página está en un contexto seguro, el token se sella con AES-GCM bajo una clave aleatoria por instalación antes de guardarse. Eso protege contra un token legible en una copia de seguridad del perfil del navegador, un perfil sincronizado, una máquina compartida, una captura de las herramientas de desarrollo o un paquete de soporte. No protege contra un script que pueda ejecutarse en el mismo origen, porque ese script puede llamar al mismo módulo de almacenamiento. Ningún diseño exclusivo del navegador puede resolverlo del todo. Los controles prácticos son, por tanto, alcance, caducidad y revocación: usa un token fine-grained limitado al repositorio que necesitas, establece una caducidad y elimina el token en GitHub cuando termines. El tráfico de GitHub va directamente del navegador a api.github.com; LadeStack no necesita custodiar la credencial. El almacenamiento del navegador sigue sin ser una copia de seguridad, así que un repositorio también es una copia sensata fuera del dispositivo.

La sincronización con GitHub es suficiente para una gran parte de los proyectos de navegador: un sitio estático, un prototipo de React o Vue, un ejercicio de clase, una pequeña herramienta interna o una demo que necesita un remoto y una fuente de despliegue. Encaja con un desarrollador individual que quiere control de versiones sin instalar Git, con un profesor que necesita una entrega reproducible y con cualquiera que trabaje en una máquina sin terminal. No es suficiente para un monorepo con submódulos, un repositorio que depende de Git LFS, un equipo que necesita commits firmados o una revisión detallada del historial, ni un proceso de release basado en hooks y múltiples remotos. Esos son trabajos de Git de escritorio, y fingir lo contrario empeoraría el flujo del navegador. El patrón útil es híbrido. Empieza en el navegador porque la primera vista previa es inmediata. Haz push cuando el proyecto tenga una forma que merezca conservarse. Abre el mismo repositorio en el escritorio cuando el trabajo necesite herramientas nativas, un depurador más profundo o un flujo Git completo. Trae los cambios de vuelta por GitHub cuando regreses al navegador. Los archivos son archivos fuente normales, así que la transición es control de versiones, no migración. Para probar la mitad del navegador, abre el Projects Dashboard en /app/projects, crea un proyecto, abre GitHub sync y haz el primer commit. La configuración completa y la referencia de funciones están en la documentación.