O que é Git? Controle de versão explicado para quem está começando a criar jogos

Você passou algumas horas trabalhando no seu jogo.

O personagem finalmente está se movimentando como deveria. Você decide melhorar mais uma coisinha.

Mexe aqui.

Mexe ali.

Testa.

E…

quebra tudo.

Você tenta desfazer.

Não funciona.

Tenta lembrar como estava antes.

Também não lembra.

Então olha para a pasta do projeto e pensa:

“Eu devia ter feito uma cópia antes.”

É normalmente nesse momento que começam a nascer arquivos como:

MeuJogo_backup

MeuJogo_backup2

MeuJogo_AGORA_VAI

MeuJogo_final

MeuJogo_final_2

MeuJogo_final_DE_VERDADE

Não julgo.

Esse é praticamente um sistema artesanal de controle de versão.

O problema é que existe uma ferramenta feita justamente para resolver isso de uma maneira muito melhor.

Ela se chama Git.

O que é Git?

Git é um sistema de controle de versão.

Essa definição parece complicada até entendermos o problema que ele resolve.

Imagine que você está jogando um RPG.

Antes de entrar em uma dungeon perigosa, você salva o jogo.

Você entra.

Toma uma decisão terrível.

Tudo dá errado.

Mas existe um save anterior.

Então você pode voltar para aquele ponto e tentar novamente.

Git faz algo conceitualmente parecido com o seu projeto.

Durante o desenvolvimento, você pode registrar determinados estados do projeto.

Esses registros formam um histórico.

Assim, em vez de depender de:

projeto_final_agora_vai_3

você passa a ter uma sequência organizada da evolução daquele projeto.

É como criar save points do desenvolvimento.

Essa não é uma descrição técnica perfeita de tudo que acontece internamente no Git — mas, para começarmos, é uma ótima maneira de pensar nele.

O que é um commit?

Agora podemos aprender nosso primeiro termo estranho.

Commit.

Um commit é um registro de determinado estado do projeto no histórico do Git.

Voltando à nossa analogia:

commit ≈ save point

Imagine que terminamos a movimentação do personagem.

Podemos registrar:

Movimentação básica funcionando

Depois criamos o pulo:

Adicionado sistema de pulo

Depois implementamos dano:

Jogador agora recebe dano dos inimigos

Nosso histórico começa a ficar assim:

Movimentação básica funcionando

↓

Adicionado sistema de pulo

↓

Jogador recebe dano

↓

Sistema de vida funcionando

Agora não temos simplesmente uma pasta cheia de arquivos.

Temos uma história da evolução do projeto.

E isso é extremamente útil quando alguma coisa dá errado.

Então Git é um backup?

Aqui precisamos tomar cuidado.

Git e backup não são exatamente a mesma coisa.

Controle de versão tem como principal objetivo registrar e organizar alterações no projeto.

Backup tem como principal objetivo manter uma cópia segura dos seus dados caso alguma coisa aconteça com o original.

Usar Git junto com um repositório remoto pode ajudar bastante na proteção do projeto, mas eu não quero que você saia daqui pensando:

“Instalei Git, portanto nunca mais preciso me preocupar com backup.”

São problemas relacionados, mas diferentes.

Vamos falar sobre repositórios remotos daqui a pouco.

O que é um repositório?

Outro termo que aparece constantemente é:

repository, ou simplesmente repositório.

Imagine uma pasta especial do seu projeto que, além dos arquivos atuais, possui as informações que o Git utiliza para acompanhar seu histórico.

Podemos pensar no repositório como:

o projeto + seu histórico controlado pelo Git.

Quando você transforma seu projeto em um repositório Git, o Git passa a conseguir acompanhar as alterações que você registra nele.

E o que é uma branch?

Aqui costuma começar a confusão.

Então vamos voltar para jogos.

Imagine que estamos desenvolvendo nosso personagem e temos uma ideia:

“E se eu adicionar um dash?”

O jogo está funcionando.

Não queremos bagunçar a versão atual enquanto experimentamos.

Podemos criar uma branch.

Pense em uma branch como uma linha do tempo alternativa.

Temos:

Linha principal

Personagem anda → pula → recebe dano

E criamos:

Linha experimental

Personagem anda → pula → recebe dano → DASH MALUCO QUE TALVEZ QUEBRE TUDO

Podemos experimentar nessa linha sem precisar tratar a linha principal como nosso laboratório.

Se a ideia for horrível, descartamos o experimento.

Se funcionar…

precisamos conhecer nosso próximo termo.

O que é merge?

Merge significa combinar históricos de desenvolvimento.

Continuando nossa analogia:

criamos uma linha do tempo alternativa para desenvolver o dash.

Testamos.

Ajustamos.

Funcionou.

Agora queremos trazer essa mudança para a linha principal.

É aí que entra o merge.

De maneira simplificada:

Branch

“Vou experimentar isso separadamente.”

Merge

“Funcionou. Quero incorporar essa mudança.”

Branches e merges possuem várias particularidades que aprenderemos quando realmente precisarmos utilizá-los.

Por enquanto, basta entender a ideia.

Git e GitHub são a mesma coisa?

Não.

Essa provavelmente é uma das confusões mais comuns de quem está conhecendo Git.

Git é a ferramenta de controle de versão.

GitHub é um serviço que pode hospedar repositórios Git remotamente e oferecer ferramentas adicionais para colaboração e desenvolvimento.

Vamos usar outra analogia.

Imagine que Git seja o sistema de saves do seu jogo.

Seu computador possui esses saves.

Mas o que acontece se o SSD morrer?

Os saves estavam no computador.

Por isso podemos trabalhar também com um repositório remoto.

Uma plataforma como GitHub pode armazenar uma cópia desse repositório remotamente.

Assim:

Git
→ controla versões.

GitHub
→ é uma plataforma que, entre outras funções, hospeda repositórios Git.

Você pode usar Git sem GitHub.

E existem outros serviços capazes de hospedar repositórios Git.

Essa diferença parece pequena, mas evita bastante confusão depois.

Por que Git é útil para quem cria jogos?

Até agora tudo isso pode parecer algo de programador.

Mas pense no que acontece durante a criação de um jogo.

Hoje o personagem anda.

Amanhã você altera a movimentação.

Depois cria inimigos.

Depois muda o sistema de dano.

Depois mexe na interface.

Depois percebe que uma mudança feita três dias atrás criou um bug.

Um projeto não permanece parado.

Ele está constantemente mudando.

O Git nos dá uma maneira estruturada de acompanhar parte dessa evolução.

E existe outro benefício importante:

experimentar fica menos assustador.

Se você sabe que possui um estado anterior registrado, fica muito mais confortável testar uma ideia.

Para o GNOR isso é especialmente interessante.

Quero que você experimente.

Quebre coisas.

Descubra por que quebraram.

Tente novamente.

Controle de versão cria uma espécie de rede de segurança para a exploração.

Git fica ainda mais importante trabalhando em equipe

Agora imagine duas pessoas trabalhando no mesmo jogo.

Você está mexendo no personagem.

Outra pessoa está trabalhando em outra parte do projeto.

Sem um sistema apropriado, rapidamente aparece a pergunta:

qual é a versão mais recente?

Começam ZIPs.

Pastas compartilhadas.

Projeto_Ned.zip

Projeto_Joao_novo.zip

Projeto_FINAL_mesmo.zip

E eventualmente duas pessoas alteram coisas que precisam ser combinadas.

Git foi projetado para permitir que diferentes históricos de trabalho sejam registrados e posteriormente integrados.

Isso não significa que conflitos desaparecem magicamente.

Eles podem acontecer.

Mas agora existe um sistema para identificar e resolver essas situações.

Git funciona perfeitamente com qualquer arquivo de jogo?

Aqui existe uma particularidade importante.

Git funciona muito bem acompanhando arquivos de texto.

Código é o exemplo mais óbvio.

Mas projetos de jogos também possuem:

• texturas;
• modelos 3D;
• áudio;
• vídeos;
• arquivos gerados pela engine;
• outros arquivos binários.

Esses arquivos podem exigir cuidados diferentes, principalmente quando são grandes.

Existe, por exemplo, o Git LFS, criado para trabalhar melhor com arquivos grandes.

Mas não precisamos aprender isso agora.

Essa é outra regra que quero seguir no GNOR:

não aprender quinze coisas porque talvez um dia precisemos delas.

Quando nossos projetos começarem a exigir isso, estudamos.

E onde o Construct 3 entra nisso?

Como nossa jornada prática vai começar pelo Construct 3, naturalmente surge uma pergunta:

preciso aprender Git antes de começar no Construct?

Não.

E eu definitivamente não quero transformar Git em mais uma barreira antes de você poder criar seu primeiro jogo.

Primeiro precisamos criar coisas.

Mas conforme nossos projetos começarem a importar de verdade, controle de versão passa a fazer cada vez mais sentido.

Por isso estou apresentando o conceito agora.

Não para você decorar comandos.

Não para instalar cinco ferramentas imediatamente.

Mas para quando ouvir:

Git

commit

repository

branch

merge

você não pensar:

“Meu Deus, começou a programação.”

Você já sabe aproximadamente o que cada coisa significa.

O que você precisa lembrar por enquanto

Se esquecer todos os termos deste artigo, lembre apenas disso:

Git registra a evolução do seu projeto.

Um commit é como registrar um save point dessa evolução.

Um repositório é o projeto acompanhado pelo Git.

Uma branch permite desenvolver em uma linha separada.

Um merge permite combinar trabalhos de linhas diferentes.

E GitHub não é Git — é uma plataforma que pode hospedar repositórios Git e oferecer ferramentas para trabalhar com eles.

Só isso já basta por enquanto.

Quando chegar o momento de realmente utilizar Git em nossos projetos, vamos aprender fazendo.

Sem decorar uma lista enorme de comandos antes de precisar deles.

Um grande abraço!