Como Subir seu Projeto Godot no GitHub (Passo a Passo)
Como subir projeto Godot no GitHub passo a passo: instalar Git, criar o repositório, configurar o .gitignore do Godot e dar o primeiro push sem travar.
Você terminou uma tarde boa de trabalho no Godot, fechou o editor e aquele pensamento voltou: e se o HD queimar amanhã? Subir o projeto Godot no GitHub resolve isso de uma vez, e de quebra te dá histórico de tudo que você mudou e um lugar para colaborar. Neste passo a passo a gente vai do zero (sem Git instalado, sem conta no GitHub) até o primeiro git push com o projeto no ar, passando pelo detalhe que mais trava iniciante: o .gitignore do Godot. É tudo comando real, nada de mágica.
Se você nunca usou controle de versão, vale entender antes o porquê de toda essa dança. É rápido.
Por que usar Git e GitHub num projeto de jogo
Três motivos, em ordem de importância para quem está começando.
O primeiro é backup. Enquanto o projeto mora só na sua máquina, ele depende de um disco que pode falhar, de um sistema que pode corromper e de um "salvei por cima sem querer" que acontece com todo mundo. Com o projeto no GitHub existe uma cópia na nuvem que você recupera de qualquer lugar. Não é backup no sentido de uma pasta copiada, é o histórico inteiro guardado fora de casa.
O segundo é histórico. Cada vez que você grava um ponto do projeto (um commit), o Git registra exatamente o que mudou e quando. Quebrou a física do personagem numa sexta à noite? Você volta para o estado de quinta sem desfazer nada na mão. Esse histórico é o que separa "perdi duas semanas" de "voltei em cinco minutos".
O terceiro é colaboração. No dia que entrar um amigo artista ou outro programador no projeto, o GitHub é o ponto de encontro: cada um trabalha na sua máquina e envia o trabalho para o mesmo lugar, sem mandar .zip por mensagem e sem sobrescrever o arquivo do outro.
Importante separar duas coisas que iniciante costuma confundir. Git é o programa que roda no seu computador e cuida do histórico. GitHub é o site que hospeda uma cópia desse histórico na nuvem. Git funciona sem GitHub, mas é o GitHub que entrega o backup remoto. Se quiser ir mais fundo no conceito de versionamento em jogos, o hub de Git e GitHub reúne o material do blog sobre o assunto.
Fechado o porquê, vamos à prática.
Passo 1: criar a conta e o repositório no GitHub
Abra o github.com e crie uma conta gratuita, se ainda não tiver. É e-mail, nome de usuário e senha, nada além disso.
Com a conta pronta, crie o repositório, que é a "casa" do seu projeto no site:
- Clique no botão New (ou no
+no canto superior direito e depois em New repository). - Em Repository name, dê um nome ao projeto. Use algo sem espaços nem acentos, tipo
meu-primeiro-jogo. - Escolha entre Public (qualquer um vê) e Private (só você e quem convidar). Para projeto pessoal, privado é uma escolha tranquila e também é gratuito.
- Não marque nenhuma das opções de "Initialize this repository" (README, .gitignore, license). A gente vai criar o repositório localmente primeiro, e marcar essas caixas agora só complica o primeiro push.
- Clique em Create repository.
O GitHub vai te mostrar uma página com uns comandos e uma URL parecida com https://github.com/seu-usuario/meu-primeiro-jogo.git. Guarde essa URL, ela é o endereço do seu repositório remoto e você vai usá-la daqui a pouco.
Passo 2: instalar o Git na sua máquina
Agora o programa que faz o trabalho de verdade.
No Windows, baixe o instalador em git-scm.com e siga o instalador clicando em avançar nas opções padrão (elas estão boas para quem começa). No Linux, geralmente é sudo apt install git ou o equivalente da sua distribuição. No macOS, instalar as ferramentas de linha de comando com xcode-select --install já traz o Git.
Depois de instalar, abra o terminal (no Windows, o Git Bash que veio junto) e confirme que deu certo:
git --version
Se aparecer um número de versão, está pronto. Antes de seguir, diga ao Git quem é você. Esse nome e e-mail ficam marcados em cada commit:
git config --global user.name "Seu Nome"
git config --global user.email "[email protected]"
Você faz essa configuração uma única vez por máquina.
Passo 3: o .gitignore do Godot (faça isso antes do primeiro commit)
Esse é o passo que mais gente pula, e é o que mais dá dor de cabeça depois. Preste atenção aqui.
Quando você roda git add ., o Git quer incluir tudo que está na pasta. Só que o Godot gera um monte de arquivo sozinho que não é o seu trabalho: a pasta .godot/, com cache e dados de import, e as pastas de builds exportados. Esses arquivos mudam o tempo todo, pesam à toa e, se forem para o GitHub, enchem o histórico de lixo e viram fonte de conflito quando você trabalha em outra máquina ou com outra pessoa.
A solução é um arquivo chamado .gitignore (com o ponto na frente, sem extensão), criado na raiz do projeto, ao lado do project.godot. Ele é uma lista do que o Git deve ignorar. Um .gitignore enxuto para Godot 4 começa assim:
# Cache e dados de import que a engine reconstrói sozinha
.godot/
# Builds exportados
export_presets.cfg
build/
*.exe
*.pck
Crie esse arquivo antes de qualquer git add. Assim o Git nunca chega a rastrear a .godot/, e o seu primeiro commit já nasce limpo. Se você esquecer e só adicionar o .gitignore depois de já ter commitado a pasta, vai precisar parar de rastreá-la com git rm -r --cached .godot/ e commitar essa remoção, trabalho que dava para evitar.
O que detalhar em cada linha, as diferenças entre Godot 4 e versões antigas e um arquivo pronto e comentado para copiar estão no guia de .gitignore para projetos de jogos. Se o seu projeto já tem bastante arte pesada (texturas grandes, áudio, modelos 3D), vale configurar também o controle de versão com Git LFS antes de subir, porque Git puro guarda uma cópia inteira de cada binário e o repositório incha rápido.
Passo 4: iniciar o Git no projeto e fazer o primeiro commit
Abra o terminal dentro da pasta do seu projeto Godot (a que tem o project.godot). No Git Bash você navega com cd caminho/da/pasta.
Primeiro, transforme a pasta num repositório Git:
git init
Isso cria uma subpasta oculta .git/ onde o Git guarda o histórico. Você não mexe nela.
Agora confira o que o Git está vendo. Esse comando você vai usar o tempo todo, é o seu "o que mudou?":
git status
Se o .gitignore estiver certo, a pasta .godot/ não deve aparecer na lista. Se aparecer, volte ao passo 3 e confirme o arquivo. Com a lista limpa, adicione todos os arquivos do projeto à área de preparo:
git add .
O ponto significa "tudo que não está ignorado". Agora grave o primeiro ponto do histórico, o primeiro commit, com uma mensagem que descreve o momento:
git commit -m "Primeiro commit: estrutura inicial do projeto"
A mensagem entre aspas depois do -m é o seu bilhete para o futuro. Capriche nela nos commits do dia a dia ("Adiciona pulo duplo", "Corrige colisão da parede") e você vai agradecer quando precisar achar onde algo quebrou.
Nesse ponto o projeto já tem histórico local. Falta mandá-lo para o GitHub.
Passo 5: conectar o remoto e dar o push
Lembra da URL que o GitHub te deu no passo 1? Agora ela entra. Primeiro, diga ao Git qual é o repositório remoto, que por convenção se chama origin:
git remote add origin https://github.com/seu-usuario/meu-primeiro-jogo.git
Troque a URL pela do seu repositório. Em seguida, garanta que o nome da sua branch principal é main, que é o padrão atual do GitHub:
git branch -M main
E, enfim, envie tudo para a nuvem:
git push -u origin main
O -u liga a sua branch local à do GitHub, então nas próximas vezes basta um git push sem o resto. Na primeira vez o Git pode pedir login; no Windows costuma abrir uma janela do navegador para você autorizar. Autorizado, atualize a página do repositório no GitHub e pronto: o seu projeto Godot está no ar, com histórico e backup.
O fluxo do dia a dia, resumido
Depois desse primeiro envio, o seu ritual de trabalho vira curto. Toda vez que terminar algo que vale guardar:
git add .
git commit -m "Descreve o que você fez"
git push
São três linhas. add prepara, commit grava o ponto no histórico, push manda para o GitHub. Faça isso ao fim de cada sessão boa de trabalho, ou sempre que concluir algo que você não quer arriscar perder. Commit pequeno e frequente é melhor que um commit gigante no fim da semana, porque te dá pontos de retorno mais precisos quando algo der errado.
Se você seguiu até aqui, já tem o essencial: Git instalado e configurado, um repositório no GitHub, um .gitignore que mantém o lixo do Godot fora do histórico, e o fluxo de três comandos para o dia a dia. O resto (branches, pull requests, trabalhar em time) você aprende quando a necessidade aparecer, e cada um desses passos vai parecer pequeno perto da primeira vez que o seu projeto sobreviver a um problema de disco sem você perder nada.
Perguntas frequentes
Preciso saber programar para subir um projeto Godot no GitHub?
Não. São uns seis comandos de Git que você aprende numa tarde: git init, git add, git commit, git remote add, git branch e git push. Você digita cada um uma vez, entende o que ele faz e pronto. Nada disso é programação de verdade, é só operar uma ferramenta. Depois do primeiro projeto no ar, o fluxo vira automático.
Qual a diferença entre Git e GitHub?
Git é o programa que roda na sua máquina e guarda o histórico do projeto em commits. GitHub é um site que hospeda uma cópia desse histórico na nuvem, serve de backup e deixa outras pessoas verem e colaborarem. Você pode usar Git sem GitHub, mas é o GitHub que te dá o backup remoto e o lugar para o projeto morar fora do seu HD.
Preciso versionar a pasta .godot/ do projeto?
Não. A pasta .godot/ guarda cache e dados de import que a engine reconstrói sozinha ao abrir o projeto. Ela muda o tempo todo, pesa à toa e não representa o seu trabalho. Por isso entra no .gitignore antes do primeiro commit. O que vai para o GitHub são as cenas (.tscn), os scripts (.gd), o project.godot e os arquivos .import ao lado de cada asset.
O que fazer se eu esqueci do .gitignore e já commitei a pasta .godot/?
Adicionar a pasta ao .gitignore depois não apaga o que já foi commitado. Você precisa parar de rastrear com git rm -r --cached .godot/ e depois fazer um novo commit dessa remoção. A partir daí o .gitignore passa a valer e a pasta some dos commits futuros, sem apagar nada do seu disco.
Meu projeto tem muita arte pesada. Git dá conta?
Git puro lida mal com binários grandes, porque guarda uma cópia inteira de cada versão e o repositório incha rápido. Se o seu jogo tem muitas texturas, áudio ou modelos 3D, configure o Git LFS para tratar esses arquivos à parte. Para projetos 2D pequenos no começo, Git puro com um bom .gitignore já resolve.
Meu repositório pode ser privado?
Pode. Na hora de criar o repositório no GitHub você escolhe entre público e privado, e repositório privado é gratuito. Público qualquer pessoa vê, privado só você e quem você convidar. Para projeto pessoal em andamento, privado é uma escolha tranquila. Você pode trocar isso depois nas configurações do repositório.
