Git para Jogos: Versionar seu Projeto Godot do Zero

Fazer jogo é acumular pequenas decisões que, de vez em quando, dão muito errado. Você mexe na física do pulo, o personagem começa a atravessar o chão, e meia hora depois não lembra mais o que estava funcionando antes. Sem controle de versão, a única saída é o Ctrl+Z desesperado ou refazer na mão. Com Git para jogos, você volta pra última versão que rodava com um comando. Esse guia ensina, do zero, a versionar um projeto Godot: instalar o Git, inicializar o repositório, montar o .gitignore certo da engine, fazer o primeiro commit e subir tudo pro GitHub. Nenhum conhecimento prévio de linha de comando necessário.

Por que versionar seu projeto de jogo

Controle de versão é um programa que tira "fotos" do seu projeto ao longo do tempo e guarda cada uma com uma etiqueta. Cada foto dessas é um commit. A qualquer momento você pode olhar o histórico, comparar duas fotos ou voltar pra uma delas. Parece burocracia, mas resolve quatro problemas reais que todo mundo que faz jogo enfrenta.

Desfazer besteira sem pânico. Esse é o motivo número um pra quem está começando. Você quer testar uma ideia maluca na mecânica, mas tem medo de quebrar o que já funciona. Com Git, você experimenta à vontade: se der ruim, volta pro último commit bom e é como se nada tivesse acontecido. A liberdade de errar sem consequência permanente muda a forma como você programa.

Histórico do que aconteceu. Daqui a dois meses você vai se perguntar "quando foi que eu mudei o sistema de inventário?". O histórico de commits responde. Cada commit tem data, mensagem e a lista exata do que mudou. É a memória do projeto, e ela não depende da sua.

Backup de verdade. HD morre, notebook é roubado, pasta é apagada por engano. Se o projeto só existe num lugar, ele não existe de verdade. Ao enviar os commits pro GitHub, você tem uma cópia fora da sua máquina, atualizada a cada envio. Não é backup manual que você esquece de fazer: faz parte do fluxo normal de trabalho.

Trabalhar em várias máquinas. Começou no PC de casa, quer continuar no notebook. Com o repositório no GitHub, você baixa o projeto em qualquer máquina, trabalha, envia de volta, e tudo fica sincronizado. O mesmo mecanismo que depois permite trabalhar em equipe já serve pro "eu de casa" e o "eu da faculdade".

Instalar e checar o Git

Antes de tudo, veja se o Git já não está instalado. Abra o terminal (no Windows, o PowerShell ou o Git Bash; no Linux e no macOS, o terminal padrão) e rode:

git --version

Se aparecer algo como git version 2.44.0, está instalado e você pode pular pra próxima seção. Se der erro de comando não encontrado, baixe em git-scm.com, o site oficial. No Windows, o instalador vem com o Git Bash, um terminal que já entende os comandos; pode aceitar as opções padrão sem medo. No Linux, normalmente é sudo apt install git (ou o gerenciador da sua distro). No macOS, instalar as ferramentas de linha de comando do Xcode já traz o Git.

Com o Git instalado, configure seu nome e e-mail uma única vez. Eles entram em cada commit pra identificar quem fez o quê:

git config --global user.name "Seu Nome"
git config --global user.email "[email protected]"

O --global diz que vale pra todos os seus projetos, então você só precisa fazer isso uma vez por máquina.

Git para jogos: o primeiro commit do seu projeto Godot

Agora o passo que transforma uma pasta comum num projeto versionado. Abra o terminal e navegue até a pasta raiz do seu projeto Godot, aquela onde fica o arquivo project.godot. No terminal, usa-se o comando cd pra entrar na pasta:

cd caminho/para/meu-jogo

Dentro dela, inicialize o repositório:

git init

Esse comando cria uma pasta escondida chamada .git dentro do projeto. É ali que o Git guarda todo o histórico. Você nunca mexe nela diretamente, e ela nunca sai do seu computador a não ser que você envie os commits pra algum lugar. A partir de agora, essa pasta está sendo "observada" pelo Git.

O .gitignore certo da Godot

Antes de fazer qualquer commit, você precisa dizer ao Git o que não versionar. A Godot gera arquivos que são lixo de cache ou resultado de exportação: eles são recriados sozinhos e não fazem sentido no repositório. Pra isso serve o arquivo .gitignore, um texto simples na raiz do projeto listando o que ignorar.

Crie um arquivo chamado .gitignore (com o ponto na frente) na raiz do projeto, com este conteúdo pra um projeto Godot 4:

# Cache da engine, recriado automaticamente ao abrir o projeto
.godot/

# Pasta de exportação dos builds
/export/

# Arquivos temporários
*.tmp

# Template de exportação Android, gerado pela engine
/android/

Vale entender cada linha, porque copiar sem entender é como você acaba versionando coisa errada:

• .godot/ é a pasta de cache que a engine cria ao importar assets e abrir o projeto no Godot 4. Ela pode pesar centenas de megabytes e é recriada do zero em qualquer máquina que abra o projeto. Versioná-la só incha o repositório e gera conflitos sem sentido.
• /export/ (ou o nome que você der à pasta de builds) guarda os executáveis que você gera ao exportar o jogo. São artefatos finais, não código-fonte. Você gera de novo quando precisar; não têm por que ocupar o histórico.
• *.tmp pega qualquer arquivo temporário que apareça pelo caminho.
• /android/ é a pasta que a Godot cria quando você instala o template de build pra Android. É gerada pela engine e específica da sua máquina.

A barra no começo (/export/) ancora a regra na raiz do projeto. O asterisco em *.tmp casa qualquer arquivo com aquela terminação. Se depois você adotar pastas próprias pra coisas temporárias, é só acrescentar uma linha aqui.

O add e o commit

Com o .gitignore no lugar, chegou a hora da primeira foto. Primeiro, veja o que o Git enxerga:

git status

Ele vai listar todos os arquivos do projeto como "não rastreados" (menos os que você mandou ignorar). Pra selecionar tudo pro próximo commit:

git add .

O ponto significa "tudo nesta pasta". Esse comando coloca os arquivos na chamada área de stage, que é a antessala do commit: nada foi gravado no histórico ainda, você só escolheu o que vai entrar. É por isso que são dois passos. Agora grave de fato:

git commit -m "Primeiro commit: estrutura inicial do projeto"

O -m vem de "message", a mensagem que descreve o commit. Pronto: você tem o primeiro ponto de retorno do seu projeto. Se daqui a uma semana tudo desandar, esse estado está salvo e acessível.

Repare no que acabou de acontecer. Versionar não é uma tarefa separada de "fazer o jogo": é parte de programar de verdade. Todo profissional que escreve código, de jogo ou de qualquer outra coisa, trabalha dentro de um fluxo de versionamento, porque programar sério é mexer em sistemas que você precisa conseguir desfazer, auditar e compartilhar. Aprender Git cedo é aprender o ofício do jeito certo, não decorar um truque à parte. Se você está no começo e quer construir essa base com método, essa é exatamente a mentalidade que vale cultivar desde o primeiro projeto.

Escrevendo uma boa mensagem de commit

A mensagem do commit é pra você do futuro, não pro Git. Uma mensagem como "ajustes" ou "coisas" é inútil: daqui a um mês ela não diz nada. Uma boa mensagem completa a frase "este commit vai...": "corrige colisão do player com paredes", "adiciona tela de game over", "ajusta velocidade do inimigo voador".

Duas regras práticas que resolvem 90% dos casos. Primeira: escreva no presente ou no imperativo, descrevendo o que a mudança faz, não o que você fez. Segunda: se a mensagem precisa de um "e" pra caber tudo (tipo "adiciona menu e corrige pulo e muda a fonte"), provavelmente deveriam ser três commits separados. Cada commit idealmente faz uma coisa.

Isso conecta direto com a frequência. Não guarde tudo pra um único commit no fim do dia. Terminou de implementar o pulo? Commit. Ajustou a câmera? Commit. Commits pequenos e frequentes criam pontos de retorno úteis: se algo quebra, você volta um passo, não o dia inteiro.

Enviando pro GitHub

Até aqui, todo o histórico mora só na sua máquina. Pra ter backup na nuvem e poder trabalhar de outros lugares, você envia o repositório pro GitHub. Crie uma conta gratuita em github.com se ainda não tiver.

No GitHub, clique em New repository, dê um nome (pode ser o nome do jogo), escolha se ele será público ou privado, e não marque pra criar README ou .gitignore, já que seu projeto local já tem o seu. Confirme a criação. O GitHub vai mostrar uma página com comandos; o que te interessa é conectar seu repositório local ao remoto.

De volta ao terminal, na pasta do projeto, rode (trocando pela URL que o GitHub te deu):

git remote add origin https://github.com/seu-usuario/seu-jogo.git

Esse comando cadastra o GitHub como destino remoto, apelidado de origin. Agora envie seus commits:

git push -u origin main

O push empurra o histórico local pro remoto. O -u origin main diz que o seu ramo local main passa a acompanhar o main do origin, então nas próximas vezes basta git push. Na primeira vez, o Git vai pedir pra você autenticar; siga o fluxo que ele indicar (hoje em dia costuma abrir o navegador ou pedir um token). Recarregue a página do GitHub: seus arquivos estão lá, com o histórico completo.

Se o comando reclamar que o ramo se chama master em vez de main, use o nome que o git status mostrou, ou renomeie com git branch -M main antes do push. Versões recentes do Git já criam main por padrão.

O fluxo diário, a partir de agora

Com tudo configurado, seu dia a dia vira um ciclo curto e repetitivo. Você trabalha no jogo pelo editor da Godot normalmente. Quando termina uma unidade de trabalho, salva no editor e, no terminal, roda três comandos:

git add .
git commit -m "descrição do que mudou"
git push

add seleciona as mudanças, commit grava no histórico local com a mensagem, push manda pro GitHub. Repita isso várias vezes ao dia, sempre que fechar uma pequena etapa. Se quiser conferir o que mudou antes de commitar, o git status mostra os arquivos alterados e o git log lista os commits anteriores, do mais recente pro mais antigo.

Essa rotina parece pouca coisa, mas é o que separa um projeto que você controla de uma pasta que vai virando um pântano. Enquanto você mantém a casa de código organizada com commits, vale cuidar também da casa de arquivos: a forma como você nomeia e distribui cenas, scripts e assets. Veja como organizar a estrutura de pastas do projeto Godot pra que o Git versione uma base limpa, não uma bagunça.

O próximo passo: arquivos grandes com Git LFS

Tem um detalhe que o fluxo acima esconde no começo e cobra depois. O Git foi feito pra versionar texto (código, cenas da Godot em formato texto, configurações), e nisso ele é excelente: guarda só o que mudou entre uma versão e outra. Mas com arquivos binários grandes, como sprites em alta resolução, faixas de áudio, texturas pesadas e builds, ele guarda o arquivo inteiro a cada alteração. Troque uma música de 10 MB cinco vezes e o repositório carrega 50 MB de histórico, mesmo que só a versão final importe.

A solução é o Git LFS (Large File Storage), uma extensão que versiona esses arquivos grandes de forma otimizada, guardando-os à parte e deixando no repositório só uma referência leve. Pra jogo, que vive de assets pesados, adotar o LFS cedo evita um repositório inchado e lento. Não precisa configurar agora, no primeiro projeto; mas assim que a arte e o áudio começarem a pesar, é o passo seguinte natural. O guia de controle de versão de jogos com Git LFS mostra como configurar.

E se, no meio desse caminho, você estiver decidindo em qual linguagem programar o jogo na Godot, vale comparar as opções com calma: o C# e o GDScript na Godot têm trade-offs diferentes, e os dois convivem bem com o fluxo de Git que você acabou de montar. Pra ver todos os materiais sobre versionamento num só lugar, passe pelo hub de Git.

Versionar o projeto é um daqueles hábitos que parecem opcionais até o dia em que salvam semanas de trabalho. O investimento é de dez minutos pra configurar e trinta segundos por commit. O retorno é a tranquilidade de nunca mais perder o que você construiu, e a liberdade de experimentar sabendo que sempre dá pra voltar. Rode o git init no seu projeto ainda hoje; o resto vira rotina rápido.