Controle de Versão para Jogos: Git, Git LFS e Como Não Perder Seu Projeto

Controle de versão para jogos não é luxo de programador experiente, é a diferença entre perder semanas de trabalho num HD que queimou e voltar ao normal em cinco minutos. Se você desenvolve um jogo (sozinho ou em time) e ainda salva tudo em pastas tipo projeto_final, projeto_final_2, projeto_AGORA_VAI, este texto é pra você. Vamos ver o que é Git, como configurar o Git LFS para os arquivos pesados de jogo, um .gitignore pronto para Godot e um fluxo diário simples que você consegue manter.

A boa notícia: Git para jogos não é mais difícil do que Git para qualquer outra coisa. O que muda é um detalhe (arquivos binários grandes) que tem solução conhecida. Resolvido esse ponto, você ganha um histórico que te protege de praticamente todos os jeitos clássicos de perder um projeto.

Por que controle de versão para jogos é inegociável

Três coisas acontecem com todo mundo que desenvolve jogos, mais cedo ou mais tarde.

A primeira: você perde arquivos. HD morre, notebook é roubado, uma pasta some numa sincronização mal feita do drive na nuvem. Sem versionamento, o trabalho some junto. Com o histórico num repositório remoto (GitHub, GitLab, o que for), seu projeto vive em pelo menos dois lugares ao mesmo tempo. A máquina queima e você clona de volta no computador novo como se nada tivesse acontecido.

A segunda: você quebra o que estava funcionando. Você mexe no sistema de pulo do personagem pra adicionar um pulo duplo e, três horas depois, percebe que quebrou a colisão com o chão e não lembra mais o que mudou. Sem histórico, você reescreve no chute. Com Git, você olha exatamente o que mudou desde a última versão que funcionava e volta atrás com um comando. Cada commit é um ponto de salvamento ao qual você sempre pode retornar.

A terceira: você trabalha com outra pessoa. Um programador e um artista no mesmo projeto, sem controle de versão, viram uma bagunça de mandar .zip por WhatsApp e perguntar "essa é a versão mais nova?". Git foi feito justamente pra várias pessoas mexerem no mesmo projeto sem pisar no trabalho uma da outra, juntando as mudanças de forma organizada.

Resumindo: controle de versão te protege contra perda de dados, contra você mesmo e contra a confusão de trabalhar em equipe. Por isso é inegociável, não importa o tamanho do jogo.

Git em 5 minutos para quem nunca usou

Git é um sistema que registra o histórico do seu projeto em pontos chamados commits. Pense em cada commit como uma foto do projeto inteiro num momento, com uma legenda escrita por você. A sequência dessas fotos é o seu histórico, e você navega por ele à vontade.

Três conceitos bastam pra começar:

• Repositório (repo): a pasta do seu projeto sob controle do Git. É onde mora todo o histórico.
• Commit: um ponto de salvamento com mensagem. "Adicionei o inimigo voador", "Consertei o bug do pulo". Bons commits têm mensagens que explicam o que mudou.
• Branch: uma linha do tempo paralela. Você cria uma branch pra testar uma ideia arriscada sem mexer na versão estável. Se der certo, junta de volta; se não, descarta e a versão principal nem fica sabendo.

Na prática, depois de instalar o Git, você abre o terminal na pasta do seu projeto e roda:

# Inicia o controle de versão nesta pasta
git init

# Diz quem é você (só na primeira vez na máquina)
git config --global user.name "Seu Nome"
git config --global user.email "[email protected]"

# Marca todos os arquivos para entrar no próximo commit
git add .

# Cria o primeiro ponto de salvamento com uma mensagem
git commit -m "Primeiro commit do projeto"

Pronto, seu projeto tem histórico. Pra mandar pra nuvem, você cria um repositório vazio no GitHub e conecta:

# Conecta sua pasta local ao repositório remoto
git remote add origin https://github.com/seu-usuario/seu-jogo.git

# Envia o histórico para o remoto
git push -u origin main

Quando quiser uma branch pra experimentar:

# Cria e já entra numa branch nova
git checkout -b experimento-pulo-duplo

Esses comandos cobrem o essencial. Não precisa decorar tudo de uma vez: na rotina, você usa basicamente add, commit e push, repetidos todo dia.

O problema específico de jogo: arquivos binários grandes

Aqui está onde game dev difere de programação comum. Um projeto de software tradicional é quase só texto: código, configuração, mais código. Git é excelente com texto porque consegue guardar só as diferenças entre versões, o que mantém o repositório leve mesmo com milhares de commits.

Jogo é outra história. Seu projeto está cheio de arquivos binários grandes: sprites e texturas em PNG, áudio em WAV e OGG, modelos 3D, fontes, vídeos. E o Git trata binário de um jeito ruim. Quando você muda um sprite de 10 MB, o Git não guarda a diferença: ele guarda uma cópia inteira nova do arquivo no histórico. Mude esse sprite vinte vezes ao longo do projeto e você tem duzentos megabytes só dele entulhados no repositório, pra sempre.

Multiplique isso por toda a sua arte e áudio. O repositório incha, fica lento pra clonar, e plataformas como o GitHub começam a reclamar do tamanho. É o motivo de tanta gente achar que "Git não serve pra jogos". Serve. Só falta uma peça.

Git LFS: a solução para os arquivos pesados

Git LFS (Large File Storage) é uma extensão oficial do Git que resolve exatamente esse problema. A ideia é simples: em vez de guardar o arquivo binário pesado dentro do histórico, o Git LFS coloca no lugar um ponteiro de texto bem pequeno (algumas linhas) e armazena o conteúdo real à parte, num espaço próprio. O histórico fica leve, e o arquivo grande só é baixado quando você de fato precisa dele.

Configurar é rápido. Primeiro, instale o Git LFS (no site oficial, ou pelo gerenciador de pacotes do seu sistema). Depois, dentro do repositório:

# Ativa o LFS neste repositório (uma vez por repo)
git lfs install

# Diz ao LFS quais tipos de arquivo ele deve gerenciar
git lfs track "*.png"
git lfs track "*.jpg"
git lfs track "*.wav"
git lfs track "*.ogg"
git lfs track "*.glb"
git lfs track "*.fbx"
git lfs track "*.blend"

Cada git lfs track adiciona uma regra a um arquivo chamado .gitattributes, que fica no projeto e vai pro repositório junto. Por isso, garanta que ele entre no commit:

# O .gitattributes precisa ir para o histórico, senão a regra não vale para o time
git add .gitattributes
git commit -m "Configura Git LFS para arte e audio"

A partir daí, sempre que você adicionar ou alterar um arquivo desses tipos, o Git LFS cuida dele automaticamente. Você continua usando git add e git commit normalmente; a mágica acontece por baixo. Um detalhe importante: configure o LFS no começo do projeto. Se você só lembrar dele depois de já ter commitado dez versões de cada sprite direto no Git, esses arquivos antigos continuam pesando no histórico, e tirá-los de lá dá trabalho. Comece certo e não precisa se preocupar.

Um .gitignore prático para Godot

Nem tudo na pasta do projeto merece ir pro histórico. A engine gera vários arquivos automáticos: cache, dados de import, builds. Versionar isso só causa conflito entre membros do time e infla o repositório à toa, porque o Godot recria essas pastas sozinho ao abrir o projeto. A ferramenta pra excluir esses arquivos é o .gitignore: um arquivo de texto na raiz do projeto listando o que o Git deve ignorar.

Para um projeto Godot 4, um .gitignore enxuto e funcional é assim:

# Cache e dados internos da engine (o Godot recria sozinho)
.godot/

# Arquivos de import de assets (gerados a partir dos originais)
*.import

# Builds e exports do jogo
/build/
/export/
*.exe
*.pck

# Arquivos de sistema operacional
.DS_Store
Thumbs.db

A regra mais importante é ignorar a pasta .godot/. Ela guarda cache e o estado de import dos assets, é recriada a cada abertura do projeto e não tem nenhum motivo pra estar no histórico. Os arquivos .import seguem a mesma lógica: são derivados dos seus assets originais e se regeneram. E a pasta de builds não vai pro repositório porque é resultado de exportação, não código fonte. Salve esse .gitignore na raiz, faça git add .gitignore e commit antes de adicionar o resto do projeto, pra esses arquivos nunca entrarem no histórico.

Fluxo de trabalho diário simples

Configurado o repositório, o LFS e o .gitignore, a rotina é curta e se repete. No fim de cada sessão de trabalho (ou sempre que terminar algo que funciona), você faz três coisas:

# 1. Marca o que mudou para o commit
git add .

# 2. Salva um ponto com uma mensagem clara do que você fez
git commit -m "Adiciona inimigo voador e ajusta dano do tiro"

# 3. Envia para o repositório remoto (backup na nuvem)
git push

Esses três comandos são 90% do seu dia a dia com Git. A regra prática: commit pequeno e frequente, com mensagem que descreve o que mudou. Não espere "terminar o jogo" pra commitar; commite cada pedaço que funciona. Quanto mais granular o histórico, mais fácil voltar a um ponto específico depois.

Se você está num time, antes de começar a trabalhar puxe o que os outros enviaram:

# Traz as mudanças que o time enviou desde a sua última sincronização
git pull

E para aquela ideia arriscada, sempre uma branch: git checkout -b nome-da-ideia. Testou, gostou, junta na principal; não gostou, descarta. A versão estável fica intocada o tempo todo. Esse é o ciclo inteiro. Simples de propósito, porque o que você mantém é o que você usa de verdade.

Alternativas para projetos grandes

Git com Git LFS cobre a esmagadora maioria dos projetos indie e de equipes pequenas. Mas vale saber o que existe além, pra quando o projeto crescer muito.

Perforce (Helix Core) é o padrão em estúdios grandes. Ele foi feito pra projetos com centenas de gigabytes de arte e dezenas de pessoas mexendo ao mesmo tempo. Dois pontos onde ele brilha: lida com arquivos gigantes melhor que o Git, e oferece lock de arquivos, ou seja, um artista "tranca" um modelo enquanto edita pra ninguém mais mexer ao mesmo tempo (binário não dá pra mesclar como código). A contrapartida é que é mais pesado de configurar e a versão completa é paga.

A novidade que vale o seu radar é o Lore, controle de versão gratuito da Epic. É um sistema da Epic Games pensado pro fluxo de jogos, com a proposta de juntar a robustez de ferramentas tipo Perforce com um modelo gratuito e open source. Pra quem prevê um projeto grande e quer evitar tanto o custo do Perforce quanto as limitações do Git com binário, é uma opção a considerar.

Para a maioria dos leitores aqui, porém, a resposta continua sendo Git mais Git LFS. É gratuito, roda em qualquer lugar, integra com GitHub e GitLab e é a ferramenta que você vai encontrar na maior parte dos tutoriais e projetos open source de jogos.

Próximo passo prático

Não deixe pra depois. Abra o projeto em que você está trabalhando agora, rode git init, configure o Git LFS com os tipos de arquivo da sua arte, crie o .gitignore do Godot e faça o primeiro commit. Em dez minutos seu projeto está protegido contra a próxima vez que o HD resolver te abandonar.

Se você ainda está montando sua base e quer encaixar versionamento na ordem certa de aprendizado, vale seguir um plano de estudos para começar sem pular etapas. E se a sua dúvida do momento é mais sobre código do que sobre fluxo de trabalho, o próximo material natural é decidir como escolher entre C# e GDScript pro seu projeto no Godot. Versionamento é o alicerce; com ele firme, dá pra construir o resto sem medo de perder o que já fez.