Sincronização com GitHub em uma IDE de navegador

Um projeto no navegador é conveniente justamente porque não precisa de pasta, runtime nem instalação. Essa mesma propriedade é a fraqueza. Os projetos vivem no perfil do navegador, que pode ser apagado por uma ferramenta de limpeza, perdido com um dispositivo ou deixado para trás quando alguém troca de computador. Exportar um ZIP cria uma cópia, mas um ZIP é um instantâneo sem histórico nem remote compartilhado. O GitHub fornece a camada que falta: um repositório fora do dispositivo, um histórico de commits, um lugar para colaborar e uma fonte natural para CI ou deploy. Isso muda o papel da IDE de navegador. Ela deixa de ser um rascunho descartável; pode ser o lugar onde um projeto pequeno é escrito, revisado e entregue. O fluxo é especialmente útil em um Chromebook, uma máquina de laboratório escolar ou um notebook corporativo bloqueado onde instalar Git não é uma opção. Também serve para um protótipo rápido que mais tarde pode migrar para um repositório no desktop. O navegador cuida do primeiro rascunho; o GitHub o torna durável.

O GB Coder expõe três ações do GitHub: Push, New repo e Pull. Push grava o projeto atual em um repositório e branch existentes. New repo cria um repositório na conta GitHub conectada e confirma o projeto como primeiro conteúdo. Pull lê um branch e importa seus arquivos de texto para o editor. Todas as requisições vão diretamente do navegador para api.github.com; nenhum servidor da LadeStack fica no meio segurando o token. Esse escopo estreito é intencional. O painel não substitui a linha de comando do Git. Ele não oferece rebase, resolução de conflito de merge, submódulos, Git LFS, commits assinados, hooks ou múltiplos remotes. Também não mostra o grafo completo de commits. Essas limitações importam em um repositório complexo. Para o projeto comum no navegador — uma página estática, um protótipo React, um exemplo didático ou um utilitário pequeno —, as três operações cobrem a parte que realmente precisa acontecer fora da aba.

A sincronização com GitHub usa um token de acesso pessoal, não uma senha nem uma conta do GB Coder. Um token clássico precisa do escopo repo. Um token fine-grained precisa de acesso de leitura e escrita a Contents, e pode ser limitado a um único repositório. A opção mais estreita é o melhor padrão: se o token vazar, o dano fica restrito aos projetos que ele alcança. A tela de conexão leva à página de tokens do GitHub e explica as duas escolhas. Cole o token, escolha se quer lembrá-lo no dispositivo e clique em Connect. O GB Coder o verifica buscando a conta e a lista de repositórios, então mostra o login conectado e o limite restante da API. Nada é gravado no repositório até que um Push ou a criação de um repositório seja confirmada. Trate o token como uma senha: não cole em uma issue, chat ou captura de tela, e revogue-o no GitHub quando não precisar mais. Um token com data de validade e acesso a um repositório é um equilíbrio razoável para este fluxo.

A aba Push pede repositório, branch, mensagem de commit e uma opção: excluir arquivos que estão faltando no projeto. Antes de qualquer coisa sair do navegador, o painel mostra a contagem de arquivos e o tamanho total. Essa prévia é útil porque o envio não é um despejo bruto das abas do editor. O GB Coder usa o mesmo construtor de arquivo que a exportação ZIP e o deploy. Um projeto simples de HTML/CSS/JavaScript vira index.html, style.css, script.js e um README. Um projeto React ou Vue vira um repositório com estrutura Vite: index.html, package.json, vite.config.js, .gitignore, um README e os arquivos-fonte em src/. Pastas de dependências e saída de build não são incluídas. A mensagem de commit é editável e o padrão é 'Update from GB Coder'. A opção de excluir arquivos ausentes fica desligada por padrão; ligue só quando o repositório deve espelhar exatamente o projeto atual, porque ela remove arquivos remotos que não existem mais localmente. No primeiro Push, escolha o branch padrão do repositório, a menos que você queira deliberadamente um branch separado.

Uma sincronização ingênua no navegador faz commit de um arquivo por vez. Isso produz um histórico barulhento e deixa o repositório meio atualizado se uma requisição falhar no meio. O GB Coder usa a API Git Data do GitHub: envia blobs, constrói uma tree sobre a tree atual do branch, cria um commit e move a referência do branch. O resultado é um único commit atômico por Push, incluindo as exclusões solicitadas pela opção correspondente. A segunda otimização é mais silenciosa, mas igualmente importante. O Git identifica o conteúdo de um arquivo por um hash SHA-1, e o navegador pode calcular esse hash localmente com WebCrypto. O GB Coder compara os arquivos locais com a tree de destino antes de enviar. Arquivos sem alteração não gastam chamadas de API, e um Push sem mudanças retorna 'already up to date' em vez de criar um commit vazio. Isso mantém o histórico legível e reserva o orçamento da API para mudanças reais. Em um projeto pequeno a diferença é invisível; em um projeto com dezenas de arquivos, é a diferença entre uma sincronização limpa e uma lenta e barulhenta.

A aba New repo cria um repositório na conta conectada. Você informa um nome e uma descrição opcional, escolhe público ou privado e decide se o GitHub deve inicializar o repositório com um README. A inicialização fica ligada por padrão porque um repositório vazio não tem cabeça de branch para o primeiro Push construir em cima. O GB Coder usa esse commit inicial, substitui o README pelos arquivos do projeto e registra o commit inicial. Com a inicialização desligada, ele mesmo cria um commit raiz e a referência do branch padrão. Depois da criação, o novo repositório e o branch padrão ficam selecionados para o próximo Push, então não há uma segunda rodada de configuração. É o caminho mais curto de uma ideia a um repositório privado e versionado. Serve para uma tarefa de aula, uma demo de cliente que deve permanecer privada ou um protótipo que precisa de uma URL para um serviço de CI. O repositório pertence à conta GitHub dona do token, não à LadeStack, e pode ser gerenciado, transferido ou excluído no GitHub depois.

Pull é a viagem de volta. Informe a URL de um repositório ou um par owner/name, escolha um branch, e o GB Coder lê a tree do branch. Ele importa arquivos de texto que um editor consegue abrir de forma útil: código-fonte, JSON, Markdown, configuração e SVG, entre outros. Ele ignora os diretórios node_modules, dist, build, .git, .next e coverage. Também limita um Pull a 200 arquivos e 512 KB por arquivo; se o branch ultrapassar qualquer um dos limites, o painel informa quantos arquivos ficaram de fora em vez de descartá-los silenciosamente. As quebras de linha são normalizadas para que um arquivo criado no Windows não pareça mudar em todas as linhas. Os arquivos importados não sobrescrevem o projeto imediatamente. Eles passam pelo mesmo fluxo de revisão e aplicação de uma importação ZIP, então você pode inspecionar a estrutura detectada antes de confirmar a mudança e desfazê-la depois. Pull é, portanto, uma boa forma de continuar o trabalho em outro dispositivo, inspecionar um repositório antes de editar ou recuperar um projeto depois que o armazenamento do navegador foi apagado. É uma importação, não um merge; se o projeto atual e o branch divergiram, revise o resultado com cuidado.

A propriedade de segurança mais importante é o que acontece quando o branch remoto avança enquanto você edita. O GB Coder atualiza a referência do branch com force desativado. Se outra pessoa fez Push nesse meio-tempo, o GitHub rejeita a atualização e o painel reporta um conflito em vez de descartar silenciosamente o trabalho dela. A resolução é deliberadamente manual: traga o branch mais recente para um projeto, revise os arquivos e faça Push novamente — ou passe para um cliente Git no desktop para um merge de verdade. Outras falhas são separadas para que a mensagem permita agir. Um token expirado produz erro de autenticação e um pedido para reconectar. Um limite de taxa mostra quando a cota do GitHub reinicia; a API permite 5.000 requisições por hora para usuários autenticados, e um Pull gasta uma requisição por arquivo. Um repositório ou branch ausente produz um erro not-found. As requisições expiram após 60 segundos, e uma operação longa pode ser cancelada no painel. Esses detalhes não são glamourosos, mas são a diferença entre uma ferramenta de sincronização confiável e uma que falha de forma ambígua.

Tokens são credenciais de alto valor. Um token do GitHub com acesso de escrita pode alterar todos os repositórios que alcança. O GB Coder mantém um token colado em um map no escopo do módulo por padrão, o que significa que ele desaparece quando a aba é fechada e nunca é gravado no localStorage. A opção 'Remember on this device' é um opt-in explícito. Quando ativada e a página está em um contexto seguro, o token é selado com AES-GCM sob uma chave aleatória por instalação antes de ser armazenado. Isso protege contra um token legível em um backup do perfil do navegador, um perfil sincronizado, uma máquina compartilhada, uma captura das ferramentas de desenvolvedor ou um pacote de suporte. Não protege contra um script que possa rodar na mesma origem, porque esse script pode chamar o mesmo módulo de armazenamento. Nenhum design somente de navegador resolve isso por completo. Os controles práticos são, portanto, escopo, validade e revogação: use um token fine-grained limitado ao repositório necessário, defina uma validade e exclua o token no GitHub quando o trabalho terminar. O tráfego do GitHub vai diretamente do navegador para api.github.com; a LadeStack não precisa guardar a credencial. O armazenamento do navegador ainda não é backup, então um repositório também é uma cópia sensata fora do dispositivo.

A sincronização com GitHub é suficiente para boa parte dos projetos no navegador: um site estático, um protótipo React ou Vue, um exercício de aula, uma pequena ferramenta interna ou uma demo que precisa de um remote e de uma fonte de deploy. Ela serve para um desenvolvedor solo que quer controle de versão sem instalar Git, um professor que precisa de uma entrega reproduzível e qualquer pessoa trabalhando em uma máquina sem terminal. Não é suficiente para um monorepo com submódulos, um repositório que depende de Git LFS, uma equipe que exige commits assinados ou uma revisão detalhada do histórico, nem um processo de release baseado em hooks e múltiplos remotes. Esses são trabalhos de Git no desktop, e fingir o contrário tornaria o fluxo no navegador pior. O padrão útil é híbrido. Comece no navegador porque a primeira prévia é imediata. Faça Push quando o projeto tiver uma forma que vale a pena manter. Abra o mesmo repositório no desktop quando o trabalho precisar de ferramentas nativas, um depurador mais profundo ou um fluxo Git completo. Traga as mudanças de volta pelo GitHub quando retornar ao navegador. Os arquivos são arquivos-fonte comuns, então a entrega é controle de versão, não migração. Para experimentar a metade do navegador, abra o Projects Dashboard em /app/projects, crie um projeto, abra o GitHub sync e faça o primeiro commit. A configuração completa e a referência de recursos estão na documentação.