gitignore para projetos de jogos: o guia direto para Godot e Unity

Você começou a usar Git no seu jogo, rodou git add ., olhou o git status e apareceram trezentos arquivos que você nunca criou. Pastas com nomes estranhos, arquivos de cache, coisas que a engine parece ter inventado sozinha. A pergunta é honesta: o que disso tudo você realmente precisa guardar? A resposta curta é um bom gitignore para projetos de jogos, e é sobre isso que este texto trata, com os arquivos prontos e comentados para Godot 4 e Unity no fim.

Se você ainda não colocou o projeto sob Git, vale ler antes o guia de controle de versão para jogos com Git e Git LFS, que cobre o começo. Aqui a gente foca num único ponto que separa um repositório limpo de um repositório que vira dor de cabeça em uma semana: decidir o que entra no histórico e o que fica de fora.

Por que ignorar arquivos gerados evita conflito e repo inchado

Toda engine trabalha com dois tipos de arquivo. O primeiro é o seu trabalho de verdade: cenas, scripts, materiais, o arquivo de configuração do projeto. Esses você escreveu ou montou, e são eles que definem o jogo. O segundo tipo é gerado pela engine a partir do primeiro: cache de importação, texturas convertidas para o formato interno, arquivos de compilação, pastas temporárias, builds exportados.

O ponto central é esse: os arquivos gerados são descartáveis. Se você apagar a pasta de cache e abrir o projeto de novo, a engine reconstrói tudo em segundos, idêntico ao que era. Eles não representam decisão nenhuma sua. São subproduto.

Versionar subproduto causa três problemas concretos.

O primeiro é o repositório inchado. Cache e builds são grandes e mudam a cada vez que você abre a engine ou exporta o jogo. Como o Git guarda o histórico completo de cada arquivo, um cache de 200 MB que muda toda semana vira gigabytes de lixo no histórico em poucos meses. Clonar o projeto passa a demorar, e esse peso nunca mais sai fácil.

O segundo é o conflito constante. Imagine dois programadores no mesmo jogo. Cada um abre a engine, o cache local de cada máquina é diferente, e toda vez que os dois dão push o Git acusa conflito naquelas pastas que ninguém edita à mão. Você perde tempo resolvendo briga entre arquivos que nem deveriam estar ali.

O terceiro é o ruído. Com cem arquivos gerados no git status, você não enxerga os cinco arquivos de verdade que mudaram. O commit vira uma caixa preta e a mensagem "atualizei umas coisas" acontece porque você já não sabe o que mudou de fato.

O .gitignore resolve tudo isso de uma vez. Ele é um arquivo de texto na raiz do repositório com uma lista de padrões. O que casar com a lista o Git simplesmente ignora, como se não existisse. Você versiona só o que importa e o histórico fica enxuto e legível.

Godot 4: o gitignore para projetos de jogos na prática

O Godot 4 é enxuto de propósito. Praticamente todo o lixo gerado pela engine mora numa única pasta oculta: .godot/. Ali dentro ficam o cache, os recursos importados (que no Godot 3 ficavam numa pasta .import/ separada), o banco de dados do editor e dados temporários. Essa pasta é 100% reconstruível e nunca deve ir para o histórico.

O que você versiona no Godot é o oposto disso: o project.godot, as cenas (.tscn), os scripts (.gd), os recursos (.tres) e, atenção, os arquivos .import que ficam ao lado de cada asset. Cada textura tem um sprite.png.import do lado, e esse arquivo pequeno guarda as configurações de importação daquela imagem. Ele precisa ser versionado. O que se ignora é a pasta .godot/ inteira, não os .import individuais.

Aqui está um .gitignore completo e comentado para um projeto Godot 4:

# Godot 4: cache, recursos importados e dados do editor.
# A engine reconstrói essa pasta ao abrir o projeto.
.godot/

# Exportação para Android (build template gerado pela engine).
/android/

# Traduções compiladas a partir dos CSV.
# O CSV fonte você versiona; o .translation é gerado.
*.translation

# Pasta de builds exportados (ajuste o nome ao seu projeto).
/build/
/builds/
/exports/

# Arquivos de crash do Mono / C#, se você usa a versão .NET.
.mono/
data_*/
mono_crash.*.json

# Sistema operacional e editores.
.DS_Store
Thumbs.db
.vscode/
.idea/

Um detalhe que merece cuidado é o export_presets.cfg. Ele guarda as configurações de exportação do jogo (plataformas, ícones, opções de build). Na maioria dos projetos você quer versioná-lo, porque é útil que o time inteiro compartilhe os mesmos presets. O problema é que esse arquivo pode acabar guardando caminhos absolutos da sua máquina e, pior, dados sensíveis de assinatura como o caminho e a senha do keystore Android. Se for o seu caso, ou você limpa esses campos antes de commitar, ou adiciona a linha export_presets.cfg ao .gitignore e combina com o time uma forma segura de compartilhar as credenciais. Não deixe senha de keystore vazar no histórico público.

Depois de criar o .gitignore, o próximo passo natural é arrumar o resto. Um repositório limpo pede também uma estrutura de pastas que faça sentido, e sobre isso escrevi um guia dedicado a organizar o projeto Godot em pastas que combina bem com este.

Unity: mais arquivos gerados, uma regra que não pode falhar

A Unity gera bem mais coisa que o Godot, e por isso o .gitignore dela é mais longo. As pastas pesadas e descartáveis são Library/ (a maior de todas, com todos os assets importados em cache), Temp/, Obj/, Build/ e Logs/. Some a isso os arquivos de projeto gerados pelo Visual Studio ou Rider, como os .csproj, .sln e .user, que a Unity recria automaticamente a partir dos seus scripts.

Antes do arquivo, a regra de ouro da Unity, aquela que não pode falhar de jeito nenhum: nunca ignore os arquivos .meta. Cada asset da Unity tem um .meta ao lado que guarda o ID único daquele arquivo e suas configurações de importação. É por esse ID que a engine liga um script a um objeto, uma textura a um material, tudo. Se você ignorar os .meta, quem clonar o projeto (ou você mesmo, em outra máquina) vai abrir a Unity e ver referências quebradas por todo lado, prefabs vazios e um trabalho de reconexão manual gigante. Versione todos os .meta. Ignore só as pastas geradas.

O .gitignore abaixo é baseado no modelo oficial da Unity, comentado para você entender cada bloco:

# Pastas geradas pela Unity. As maiores e mais descartáveis.
# O padrão [Ll] cobre a variação de maiúscula/minúscula do nome.
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/

# Capturas de memória: podem ficar enormes e conter dados sensíveis.
/[Mm]emoryCaptures/

# Plugin do Rider gerado automaticamente.
/[Aa]ssets/Plugins/Editor/JetBrains*

# Cache do Visual Studio e do Gradle.
.vs/
.gradle/

# Arquivos de solução e projeto gerados (a Unity recria sozinha).
ExportedObj/
*.csproj
*.unityproj
*.sln
*.suo
*.tmp
*.user
*.userprefs
*.pidb
*.booproj
*.svd
*.pdb
*.mdb
*.opendb
*.VC.db

# Relatório de crash gerado pela Unity.
sysinfo.txt

# Builds e pacotes exportados.
*.apk
*.aab
*.unitypackage
*.app

# Addressables empacotados.
/[Aa]ssets/[Aa]ddressable[Aa]ssets[Dd]ata/*/*.bin*

# StreamingAssets gerados para Android.
/[Aa]ssets/[Ss]treamingAssets/aa.meta
/[Aa]ssets/[Ss]treamingAssets/aa/*

Repare que em nenhum lugar existe uma linha *.meta genérica ignorando todos os metas. As únicas exceções são metas de pastas que já são ignoradas por inteiro, como o aa.meta dos StreamingAssets gerados. Fora isso, todo .meta vai para o histórico.

E os binários grandes? Aí entra o Git LFS

O .gitignore resolve o lixo gerado, mas não resolve outro jeito de inchar o repositório: commitar arquivos binários grandes de verdade, os que fazem parte do seu jogo. Texturas em alta resolução, faixas de áudio, modelos 3D, vídeos. Esses você quer versionar, porque são o conteúdo do jogo, mas o Git puro lida mal com eles: guarda uma cópia inteira a cada mudança e o repositório dispara de tamanho.

A solução não é o .gitignore, é o Git LFS (Large File Storage). Ele substitui os arquivos pesados por ponteiros leves no histórico e guarda o conteúdo de fato à parte. Você diz ao LFS quais extensões ele deve gerenciar (por exemplo *.png, *.wav, *.fbx) e o Git passa a tratar esses arquivos de forma otimizada. É um assunto próprio, que detalhei no guia de controle de versão para jogos com Git e Git LFS. A dupla .gitignore mais Git LFS cobre os dois problemas: o primeiro tira o lixo do caminho, o segundo domestica o peso legítimo.

Já commitei uma pasta que não devia. E agora?

Acontece com todo mundo. Você configura o .gitignore só depois de já ter dado o primeiro git add . com a Library/ ou a .godot/ dentro. O detalhe importante: adicionar a pasta ao .gitignore agora não remove o que já está no histórico. O Git continua rastreando o que já rastreava.

O conserto é parar de rastrear o arquivo, sem apagá-lo do seu disco:

# Remove a pasta do rastreamento do Git, mas mantém no seu disco.
# Troque .godot pelo nome da pasta que você quer parar de versionar.
git rm -r --cached .godot

# Confirma a remoção do rastreamento em um commit.
git commit -m "Remove pasta gerada do controle de versao"

O --cached é a peça central: ele tira o arquivo do índice do Git sem deletar nada da sua máquina. A partir desse commit, o .gitignore passa a valer e a pasta some dos commits futuros. Ela continua ali no seu computador, funcionando normalmente, só não vai mais para o histórico.

O resumo que você leva pra prática

Versionar um jogo é decidir bem o que guardar. O .gitignore é a ferramenta dessa decisão, e a lógica é sempre a mesma nas duas engines: o que você criou vai para o histórico, o que a engine gera fica de fora, e binário grande de verdade vai para o Git LFS. No Godot 4, ignore a .godot/ e cuide do export_presets.cfg. Na Unity, ignore Library/, Temp/, Obj/ e companhia, mas nunca os .meta.

Copie o arquivo certo para a raiz do seu projeto, ajuste os nomes das pastas de build ao seu caso, e o git status volta a mostrar só o que interessa. Se essa arrumação toda ainda parece muita coisa para aprender sozinho, vale pensar se faz sentido aprender a criar jogos por conta própria ou com um curso que já te entrega o fluxo montado. De qualquer forma, um repositório limpo é daquelas coisas que você configura uma vez e agradece por meses.