Git e GitHub para Iniciantes: Como Versionar o App que você criou com IA [2026]

Um prompt mal formulado pode apagar em trinta segundos o app que você levou um fim de semana inteiro para criar com IA. Quem já pediu ao agente para "só ajustar o botão" e viu a tela de login sumir sabe do que estamos falando. Este guia de GitHub para iniciantes resolve exatamente esse problema: ele dá ao seu projeto um histórico completo, com a possibilidade de voltar a qualquer versão que funcionava.

Na Marfin, todo projeto nasce com um repositório. Pode ser uma landing page feita no Lovable, um painel interno construído no Cursor ou uma automação que o Claude Code escreveu sozinho no terminal. A regra vale para tudo, porque o vibe coding acelera a criação e acelera também a quantidade de coisas que podem quebrar. Git e GitHub são a rede de segurança que deixa a gente experimentar rápido sem medo de perder trabalho.

Ao longo do texto, explicamos o que é Git, o que é GitHub, como criar o primeiro repositório, como conectar as ferramentas de IA que você já usa, o que nunca subir para a nuvem e quanto custa cada plano. Tudo pensado para quem cria com IA e quer aprender o mínimo necessário para trabalhar com segurança, sem decorar dezenas de comandos.

Link para esta seçãoO que é Git e o que é GitHub, explicado para quem nunca programou

A confusão mais comum de quem procura git para iniciantes é misturar Git e GitHub. São duas peças diferentes que trabalham juntas, e entender a divisão entre elas resolve metade das dúvidas que aparecem depois.

Link para esta seçãoGit: o histórico que mora no seu computador

O Git é um programa de controle de versão criado em 2005 por Linus Torvalds, o mesmo criador do Linux. Ele roda na sua máquina e acompanha uma pasta. Toda vez que você decide registrar o estado atual dos arquivos, o Git tira uma espécie de fotografia do projeto e guarda junto com uma mensagem explicando o que mudou. Essa fotografia se chama commit.

Cada commit tem um identificador único, um autor, uma data e uma mensagem. Com o tempo, a sequência de commits vira a linha do tempo do seu app. Você consegue comparar duas versões, descobrir em qual momento um bug apareceu e voltar a um estado anterior com um único comando. A pasta que o Git acompanha recebe o nome de repositório, ou repo, para encurtar.

O Git também trabalha com branches, que são linhas paralelas de desenvolvimento. Pense numa branch como uma cópia do projeto onde você testa uma ideia sem mexer na versão principal. Se a ideia funcionar, você junta a branch de volta com um merge. Se der errado, basta apagar a branch e seguir a vida.

Link para esta seçãoGitHub: a cópia na nuvem que guarda tudo

O GitHub é um serviço online, hoje da Microsoft, que hospeda repositórios Git. Quando você envia seus commits para lá, faz um push. Quando baixa as mudanças que estão lá, faz um pull. E quando copia um repositório inteiro para uma máquina nova, faz um clone.

Além de guardar o código, o GitHub adiciona uma camada de colaboração e automação em cima do Git. Lá ficam os pull requests (pedidos para juntar uma branch na principal com revisão), as issues (lista de tarefas e bugs), o GitHub Actions (automações que rodam a cada push) e o GitHub Pages (hospedagem gratuita de sites estáticos). Plataformas como Vercel, Netlify e Supabase se conectam direto no GitHub para publicar e sincronizar o seu projeto.

Link para esta seçãoOs termos que você vai ouvir toda semana

Três palavras aparecem o tempo todo e merecem uma explicação rápida. O diff é a comparação entre duas versões de um arquivo, com as linhas removidas em vermelho e as adicionadas em verde. O stage é a área de preparação onde você escolhe quais mudanças vão entrar no próximo commit, o que permite separar alterações diferentes em commits diferentes. E o fork é uma cópia de um repositório de outra pessoa para a sua conta, muito usada para estudar projetos open source ou partir de um template pronto.

Resumindo a divisão: o Git cuida do histórico, e o GitHub cuida do backup, do compartilhamento e da integração com o resto do seu stack. Dá para usar Git sem GitHub, mas no contexto de apps criados com IA os dois quase sempre andam juntos.

Link para esta seçãoVersionar código virou obrigação para quem cria apps com IA

Quando um desenvolvedor escreve código à mão, cada mudança passa pela cabeça dele antes de chegar ao arquivo. Com agentes de IA, o ritmo muda completamente. O Claude Code, a ferramenta de programação com IA que mais usamos na Marfin, consegue editar quinze arquivos numa única tarefa. O Cursor, a IDE que usamos para building no dia a dia, aplica mudanças em vários pontos do projeto com um clique. Isso é ótimo para a produtividade e perigoso para quem trabalha sem histórico.

O cenário que mais vemos acontecer é este: o app está funcionando, a pessoa pede uma melhoria, o agente reescreve uma parte importante, a melhoria quebra outra coisa e, depois de cinco prompts tentando consertar, ninguém lembra mais como era a versão boa. Com Git, a solução leva dez segundos. Você volta para o último commit estável e tenta de novo com um prompt melhor.

Existe também um motivo prático ligado à publicação. Quase todo caminho de deploy de app com IA passa por um repositório no GitHub. A Vercel, por exemplo, publica uma nova versão do site a cada push na branch principal e cria uma URL de preview para cada branch. Sem repositório, você fica preso ao botão de publicar da ferramenta onde criou o app.

E tem a questão da portabilidade. Um projeto que existe apenas dentro de uma plataforma no-code depende dela para sempre. Com o código no GitHub, você pode abrir o mesmo projeto no Cursor, pedir uma refatoração ao Claude Code ou contratar um desenvolvedor para continuar de onde você parou. O repositório vira o ativo da empresa, independente da ferramenta que gerou o código.

Link para esta seçãoGitHub para iniciantes: criando a conta e o primeiro repositório

Agora a parte prática. Este passo a passo de GitHub para iniciantes considera que você já tem um projeto numa pasta do computador, seja um app exportado de uma ferramenta de vibe coding, seja algo que o Claude Code criou do zero. Se ainda está sem projeto, vale começar pelo nosso guia de como criar app sem programar e voltar aqui depois.

Link para esta seçãoCriando a conta e protegendo o acesso

Entre em github.com, clique em Sign up e escolha um nome de usuário que você teria orgulho de mostrar num currículo, porque ele aparece na URL de todos os seus repositórios. O plano gratuito já libera repositórios públicos e privados ilimitados, então dá para começar sem gastar nada.

Logo depois do cadastro, ative a autenticação em dois fatores nas configurações de segurança. O GitHub passou a exigir 2FA de quem contribui com código em 2023 e, mais importante, o seu repositório vai guardar a lógica inteira do seu produto. Use um app autenticador ou uma chave de segurança física.

Outra decisão logo no início é a visibilidade do repositório. Para apps comerciais, produtos de clientes e qualquer coisa com regra de negócio da empresa, escolha privado. Repositórios públicos fazem sentido para portfólio, projetos open source e templates que você quer compartilhar com a comunidade. Dá para mudar a visibilidade depois nas configurações, mas tudo que ficou público por um tempo pode ter sido copiado.

Link para esta seçãoInstalando o Git na sua máquina

No macOS, o jeito mais rápido é abrir o Terminal e digitar git --version. Se o Git ainda estiver ausente, o sistema oferece instalar as ferramentas de linha de comando da Apple automaticamente. No Windows, baixe o instalador em git-scm.com e aceite as opções padrão. No Linux, o Git costuma vir instalado ou fica a um comando de distância no gerenciador de pacotes da sua distribuição.

Depois de instalar, configure seu nome e e-mail. Use o mesmo e-mail da conta do GitHub para que os commits apareçam associados ao seu perfil.

git config --global user.name "Seu Nome"
git config --global user.email "voce@empresa.com"

Link para esta seçãoO primeiro commit e o primeiro push

Antes de tudo, crie o repositório vazio no site do GitHub clicando em New repository. Escolha um nome, marque como privado se o projeto for comercial e deixe desmarcadas as opções de criar README e .gitignore, porque você já tem arquivos locais. O GitHub mostra na tela os comandos exatos com a URL certa do seu repositório, então basta copiar.

Com o terminal aberto dentro da pasta do projeto, poucos comandos resolvem o primeiro versionamento. O git init transforma a pasta em repositório. O git add . marca todos os arquivos para entrar no próximo commit. O git commit cria a fotografia com uma mensagem. O git remote add diz ao Git onde fica o repositório no GitHub, e o git push envia tudo para lá.

git init
git add .
git commit -m "Primeira versão do app"
git branch -M main
git remote add origin https://github.com/seu-usuario/meu-app.git
git push -u origin main

Na primeira vez que você fizer push, o Git vai pedir autenticação. A forma mais simples hoje é instalar o GitHub CLI (o comando gh) e rodar gh auth login, que abre o navegador e resolve o login sem você precisar criar tokens manualmente. A senha da conta deixou de funcionar para push via HTTPS em 2021, então qualquer tutorial antigo que peça a senha está desatualizado.

Link para esta seçãoComo usar o GitHub sem decorar comandos

O terminal assusta muita gente, e tudo bem. Existem três caminhos para usar Git no dia a dia sem digitar comando nenhum, e nós usamos os três dependendo do contexto.

Link para esta seçãoGitHub Desktop

O GitHub Desktop é o aplicativo oficial e gratuito para macOS e Windows. Ele mostra quais arquivos mudaram, com o que saiu em vermelho e o que entrou em verde, tem um campo para escrever a mensagem do commit e um botão para enviar tudo ao GitHub. Para quem está começando, é a forma mais visual de entender o que cada operação faz. Criar branches, trocar entre elas e clonar repositórios também são ações de um clique, e o histórico de commits aparece numa aba lateral fácil de navegar.

Link para esta seçãoPelo painel do Cursor

O Cursor herdou do VS Code um painel de Source Control completo. Você vê o diff de cada arquivo, faz stage, escreve a mensagem e faz commit sem sair da IDE. O Cursor ainda gera a mensagem do commit com IA a partir das mudanças, o que economiza tempo e deixa o histórico mais descritivo. Se você ainda está escolhendo editor, nosso ranking das melhores IDEs com IA em 2026 compara Cursor, Windsurf e as outras opções lado a lado.

Num fluxo típico nosso, o Cursor aplica uma mudança, nós testamos no navegador e, se tudo funcionou, o commit sai na mesma hora. Esse hábito de commitar a cada passo que dá certo é o que mais protege o projeto.

Link para esta seçãoPedindo para o Claude Code fazer por você

O Claude Code roda no terminal e entende Git nativamente. Você pode pedir em português mesmo: "cria um commit com as mudanças de hoje", "abre uma branch nova para testar o checkout" ou "volta o arquivo de login para como estava no commit de ontem". Ele lê o histórico, executa os comandos certos e explica o que fez. Com o GitHub CLI instalado, ele também abre pull requests, lê issues e acompanha o resultado das automações do GitHub Actions.

Com o Opus 4.8, lançado em 28 de maio de 2026, a Anthropic informa que o modelo comete quatro vezes menos erros sem avisar, o que dá mais confiança quando a tarefa envolve mexer no histórico do projeto. Mesmo assim, mantemos a regra de revisar o diff antes de confirmar qualquer push para a branch principal.

Link para esta seçãoLovable e GitHub: conectando as ferramentas de vibe coding

Boa parte de quem procura GitHub para iniciantes chega aqui depois de criar um app no Lovable, no Bolt.new ou no V0. A boa notícia é que todas essas ferramentas conversam com o GitHub, cada uma do seu jeito.

Link para esta seçãoLovable: sincronização bidirecional

A integração do Lovable com o GitHub é a mais completa do grupo. Nas configurações do projeto, você conecta sua conta, escolhe a organização e o Lovable cria o repositório automaticamente. A partir daí, a sincronização funciona nos dois sentidos: o que você muda no Lovable vira commit no GitHub, e o que alguém muda no GitHub (inclusive pelo Cursor ou pelo Claude Code) aparece de volta no Lovable.

Esse fluxo híbrido é o que mais usamos com clientes. O time de marketing ajusta textos e layout com o Visual Edits do Lovable, enquanto alguém mais técnico abre o mesmo repositório no Cursor para implementar uma integração com o Supabase. Ninguém precisa exportar ZIP nem copiar arquivo de um lado para o outro. No nosso tutorial do Lovable mostramos essa conexão passo a passo.

Uma recomendação importante: conecte o GitHub no primeiro dia do projeto. Quanto antes o histórico começar, mais pontos de restauração você terá quando precisar.

Link para esta seçãoBolt.new e V0

O Bolt.new também oferece integração com GitHub e exportação do código, e funciona bem como alternativa para protótipos rápidos. O V0 da Vercel, ótimo para gerar componentes de interface em React, permite levar o código para um repositório e publicar direto na Vercel.

Independente da ferramenta, a lógica é a mesma. O código precisa morar num repositório seu, numa conta sua. Se a plataforma mudar de preço, sair do ar ou deixar de atender o que você precisa, o projeto continua intacto e pronto para ser aberto em qualquer editor.

Link para esta seçãoUm fluxo real: do Lovable ao deploy com tudo versionado

Para deixar o processo concreto, vale mostrar como um projeto típico anda aqui dentro. Imagine uma página de captura de leads com um pequeno painel administrativo. O primeiro rascunho nasce no Lovable, com o Agent Mode montando as telas e a integração nativa com o Supabase cuidando do banco e da autenticação. No mesmo dia, conectamos o GitHub e o primeiro commit já registra essa versão inicial.

Quando chega a hora de implementar algo mais específico, como um webhook que manda cada lead novo para o CRM, abrimos o repositório no Cursor ou chamamos o Claude Code no terminal. Criamos uma branch chamada webhook-crm, pedimos a implementação, testamos localmente e abrimos um pull request. A Vercel gera uma URL de preview para essa branch, e a pessoa responsável pelo projeto testa o fluxo completo num link real.

Com o preview aprovado, fazemos o merge na main. A Vercel publica a nova versão em produção, e o Lovable puxa as mudanças de volta pela sincronização com o GitHub, então o time de marketing continua editando a página normalmente. Se alguma coisa der errado depois do merge, um revert desfaz a mudança e a Vercel republica a versão anterior em poucos minutos.

Link para esta seçãoBranches, pull requests e como voltar no tempo

Depois do primeiro push, o próximo passo é aprender três operações que separam quem só faz backup de quem realmente versiona código: trabalhar em branches, revisar com pull requests e desfazer erros.

Link para esta seçãoBranches para testar sem medo

A branch main é a versão oficial do seu app, aquela que está publicada. Toda mudança maior deve nascer numa branch separada. Quer testar um novo fluxo de checkout? Crie uma branch chamada checkout-novo, peça a mudança para a IA e teste à vontade. Se ficar bom, junte na main. Se ficar ruim, apague a branch e a main continua exatamente como estava.

git switch -c checkout-novo

No GitHub Desktop, o mesmo resultado sai pelo menu Branch, opção New branch. No Cursor, pelo nome da branch que aparece no canto inferior da janela.

Link para esta seçãoPull request mesmo trabalhando sozinho

Pull request é o pedido formal para juntar uma branch na principal. Parece burocracia para quem trabalha sozinho, mas traz uma vantagem enorme: o GitHub mostra todas as mudanças da branch numa tela só, arquivo por arquivo. Esse é o melhor lugar para revisar o que a IA fez antes de colocar no ar.

Se o projeto estiver conectado à Vercel, cada pull request ganha uma URL de preview própria, então você testa a versão nova num link real antes do merge. E se você assina o GitHub Copilot, pode pedir uma revisão automática do pull request direto na interface, com apontamentos de bugs e sugestões linha por linha.

Link para esta seçãoDesfazendo erros

Aqui está o motivo número um para usar Git com IA. Se você ainda está sem commit e quer descartar tudo que a IA mudou num arquivo, use git restore com o nome do arquivo. Se o commit já foi feito e você quer desfazer aquele commit específico, o git revert cria um novo commit que anula o anterior, mantendo o histórico limpo e sem apagar nada. Para ver a lista de versões e escolher para onde voltar, o git log --oneline mostra cada commit com seu identificador curto.

git log --oneline
git restore src/app/login.tsx
git revert a1b2c3d

Evite o git reset --hard enquanto estiver aprendendo. Ele apaga mudanças de forma definitiva e está por trás da maioria das histórias tristes envolvendo Git. Se precisar de algo mais drástico, peça ao Claude Code para explicar as opções antes de executar qualquer comando.

Link para esta seçãoO que nunca subir para o GitHub

O erro mais caro de quem está começando é publicar senhas e chaves de API no repositório. Bots varrem o GitHub o tempo todo procurando chaves expostas da OpenAI, da Anthropic, da AWS e do Stripe, e uma chave vazada pode virar uma fatura de milhares de dólares em poucas horas.

A proteção começa no arquivo .gitignore, que fica na raiz do projeto e lista o que o Git deve ignorar. Ele precisa conter, no mínimo, o arquivo .env (onde ficam as variáveis de ambiente), a pasta node_modules (as dependências, que são reinstaladas com npm install), as pastas de build como .next e dist, e arquivos de sistema como .DS_Store. Projetos criados com Next.js, Vite e a maioria das ferramentas de vibe coding já vêm com um .gitignore pronto, mas vale conferir antes do primeiro commit.

.env
.env.local
node_modules/
.next/
dist/
.DS_Store

Atenção especial para quem usa Supabase. A chave pública (anon, ou publishable nos projetos mais novos) pode aparecer no frontend, desde que as políticas de Row Level Security estejam ativas em todas as tabelas. A chave service_role (ou secret) ignora todas as regras de segurança e jamais deve sair do servidor ou aparecer em algum commit. Se ela vazar, gere uma nova no painel do Supabase imediatamente.

Se você descobrir que uma chave foi parar no histórico, apagar o arquivo num novo commit resolve pouco, porque a versão antiga continua acessível para quem olhar os commits anteriores. O caminho certo é revogar a chave no serviço, gerar outra e só então limpar o histórico, se for necessário. O GitHub ajuda com o secret scanning e o push protection, que bloqueiam o push quando detectam formatos de chave conhecidos, mas a responsabilidade continua sendo de quem faz o commit.

Link para esta seçãoGitHub, GitLab ou Bitbucket: qual escolher para versionar código

Existem outras plataformas de hospedagem para repositórios Git, e vale saber o que cada uma oferece. O GitLab tem um plano gratuito generoso, um CI/CD integrado muito maduro e pode ser instalado nos seus próprios servidores, o que atrai empresas com exigências rígidas de compliance. O Bitbucket, da Atlassian, faz sentido para times que já vivem no Jira e no Confluence.

Para quem está começando e cria apps com IA, a recomendação da Marfin é o GitHub, por três motivos práticos. Primeiro, é onde as integrações estão: Lovable, Bolt.new, V0, Vercel, Supabase e Netlify conectam com GitHub em um clique, enquanto o suporte às outras plataformas varia bastante. Segundo, é a plataforma que os agentes de IA conhecem melhor, já que o Claude Code, o Cursor e o Devin operam o GitHub CLI com fluência. Terceiro, é onde está a comunidade, com a maior base de projetos open source do mundo para você estudar, copiar ideias e contribuir.

Link para esta seçãoPreços e planos do GitHub e do GitHub Copilot

O plano gratuito do GitHub cobre praticamente tudo que um iniciante precisa. Repositórios públicos e privados são ilimitados, com colaboradores ilimitados, 2.000 minutos mensais de GitHub Actions e 500 MB de armazenamento de pacotes. Os planos pagos fazem sentido quando o time cresce e precisa de branches protegidas em repositórios privados, revisores obrigatórios e controles de acesso mais finos.

O GitHub Copilot é cobrado à parte. Desde 1º de junho de 2026, os planos funcionam com AI Credits, em que cada crédito vale US$ 0,01 e o consumo depende dos tokens usados em cada interação. As sugestões de código no editor (code completions) ficam fora dessa conta, que é consumida por chat, agent mode e revisão de pull requests.

Na Marfin, o Copilot entra como complemento. O autocomplete dele continua sendo o melhor do mercado, e para tarefas completas o Claude Code segue como nossa ferramenta principal. Para versionar seu app, a conta fecha em zero: Git, GitHub Free e GitHub Desktop são gratuitos. Os valores acima foram conferidos nas páginas oficiais em outubro de 2026 e podem mudar, então confira antes de assinar.

Link para esta seção8 dicas de GitHub para iniciantes que criam apps com IA

1. Faça commit a cada mudança que funciona. Testou, funcionou, commitou. Commits pequenos e frequentes viram pontos de restauração precisos, e voltar para uma versão de dez minutos atrás é muito mais simples do que voltar para uma de três dias.

2. Escreva mensagens que façam sentido daqui a seis meses. "Adiciona filtro por data na lista de pedidos" ajuda muito mais do que "ajustes" ou "fix". Se der preguiça, peça para o Cursor ou o Claude Code gerarem a mensagem a partir do diff.

3. Commite antes de cada prompt grande. Antes de pedir uma refatoração ou uma feature nova para a IA, garanta que o estado atual está salvo. Se o agente se perder no meio do caminho, você descarta tudo com um comando e recomeça do ponto seguro.

4. Configure o .gitignore antes do primeiro push. Confira se .env, node_modules e as pastas de build estão listados. Evitar que um segredo entre no histórico dá muito menos trabalho do que tirá-lo de lá depois.

5. Use branches para experimentos. Toda ideia que você ainda está avaliando merece uma branch própria. A main fica sempre estável e publicável, e você ganha liberdade para testar sem medo.

6. Leia o diff antes de confirmar. A IA escreve rápido e às vezes mexe em arquivos fora do escopo do pedido. Gastar dois minutos olhando as mudanças no GitHub Desktop ou no Cursor evita surpresas em produção.

7. Conecte o repositório ao deploy. Ligue o GitHub à Vercel ou à Netlify para que cada push na main publique o site automaticamente e cada branch ganhe uma URL de preview. O versionamento passa a controlar também o que está no ar.

8. Escreva um README curto. Um arquivo README.md explicando o que o projeto faz, como rodar localmente e quais variáveis de ambiente ele usa ajuda qualquer pessoa, ou qualquer agente de IA, a entrar no projeto rápido. O Claude Code lê esse arquivo e o CLAUDE.md para entender o contexto antes de mexer no código.

Git e GitHub parecem intimidadores na primeira semana e viram hábito na segunda. O ganho aparece no primeiro dia em que a IA quebra alguma coisa e você volta para a versão boa em segundos, sem drama e sem perder o trabalho de horas.

Se você está começando agora, o caminho mais curto é este: crie a conta, instale o GitHub Desktop, conecte o projeto que você já tem e faça o primeiro commit hoje. Quando se sentir confortável, passe a commitar pelo Cursor e a pedir ajuda ao Claude Code para as operações mais avançadas. Em poucas semanas, branches, pull requests e reverts vão fazer parte da sua rotina de criação com IA tanto quanto escrever prompts.

Na Marfin, nenhum projeto vai para produção sem repositório, e essa regra já nos salvou mais vezes do que conseguimos contar. Com o código versionado, você escolhe livremente onde continuar o projeto, seja no Lovable, no Cursor ou no terminal com o Claude Code.

Leia também:

• O que é vibe coding: guia completo
• Lovable tutorial: como criar apps com IA sem programar
• Deploy de app com IA: como colocar seu projeto no ar
• Como criar app sem programar
• V0 da Vercel: tutorial completo
• Lovable vs Bolt.new vs V0: comparativo completo de preços e testes
• Como criar um site com IA: ferramentas de vibe coding na prática
• No-code: o guia para criar sem programar
• Melhores IDEs com IA em 2026