O que é Git: versionar código e por que ele não é o GitHub

Git é o programa que registra versões do seu projeto. Ele permite descobrir o que mudou, quem mudou e por que uma decisão foi tomada, além de voltar a um estado anterior sem manter uma coleção de pastas chamadas final, final-2 e agora-vai. GitHub é um serviço que hospeda repositórios Git e acrescenta recursos de colaboração. Você usa Git sem GitHub; o contrário não faz sentido para um repositório de código.

Todos os resultados desta lição saíram de um catálogo de livraria criado em um diretório temporário. O ambiente foi conferido antes do primeiro comando:

git --version

Por que uma sequência de ZIPs não resolve

Uma cópia compactada preserva arquivos, mas não explica a relação entre as versões. Você precisa adivinhar se loja-final-3.zip veio antes ou depois de loja-final-corrigida.zip, quem alterou o preço e qual arquivo motivou a nova cópia. Também duplica tudo, mesmo quando apenas uma linha mudou.

Pense no Git como o livro-caixa da livraria. Cada lançamento tem uma identidade, uma data, uma pessoa responsável e aponta para o lançamento anterior. A analogia ajuda a entender a sequência; o limite é que um commit não registra apenas uma linha contábil. Ele referencia um retrato completo dos arquivos naquele instante.

O primeiro passo transforma a pasta comum em repositório:

LAB=$(mktemp -d /tmp/grupo-git-loja.XXXXXX)
git init -b main "$LAB/loja"

O comando cria a pasta oculta .git. O catálogo continua sendo uma pasta normal: seu editor, seus testes e sua aplicação não precisam saber que o Git existe. É .git que guarda objetos, referências, configuração e movimentos recentes do HEAD. Remover essa pasta não apaga o catálogo, mas elimina a memória de versionamento.

O primeiro estado ainda não é uma versão

Depois de criar README.md e catalogo.txt, o Git reconhece que os arquivos existem, porém ainda não os acompanha:

git status --short

?? significa untracked, ou não rastreado. O Git não inclui tudo sozinho porque arquivos temporários, segredos e dependências podem morar na mesma pasta. Você escolhe o conteúdo do próximo retrato com git add.

git add README.md catalogo.txt
git commit -m "docs: inicia catálogo"

O commit recebeu o identificador curto 9ba9c22. Ele não é um número de versão escolhido por você. É o início de um hash calculado a partir do conteúdo e dos metadados do objeto. No mesmo laboratório, mais duas mudanças produziram uma cadeia que pode ser lida de cima para baixo:

git --no-pager log --oneline --decorate -3

HEAD indica o ponto em que você está trabalhando; main é o nome da branch. Cada linha resume um commit, mas o objeto real guarda mais informações.

Um commit aponta para o retrato e para o pai

O comando de baixo nível cat-file permite abrir o commit sem uma interface gráfica:

git cat-file -p HEAD

Há um tree, que representa o retrato, e um parent, que liga a versão à anterior. Autor, data e mensagem completam o registro. O primeiro commit não tem pai; um commit de merge costuma ter dois. Essa estrutura explica por que o Git consegue desenhar o histórico como um grafo.

Abrindo a árvore, aparecem os arquivos e os blobs de conteúdo:

git cat-file -p 9335cab2857a9f269f1188529d014768e3ad5eff

Isso comprova uma diferença importante: o commit não é apenas um arquivo de diferenças. Ele referencia o estado completo. O Git economiza espaço ao reaproveitar objetos cujo conteúdo não mudou e ao compactar objetos durante a manutenção. No laboratório com três commits, a estrutura inteira ocupou:

du -sh .git

Esse número pertence ao exemplo pequeno, não é uma promessa de tamanho para qualquer projeto. Arquivos binários grandes e que mudam com frequência fazem o histórico crescer muito mais que texto-fonte.

Working tree, stage e repositório

Você vai encontrar três nomes na documentação. Working tree é o que está visível e editável na pasta. Stage, ou índice, é a seleção preparada pelo git add. Repositório é o histórico gravado por git commit. Imagine a bancada, a caixa de despacho e o arquivo da livraria: você trabalha na bancada, separa exatamente o que vai no pacote e só então arquiva uma versão.

O limite da comparação é importante: o stage não move nem duplica seus arquivos como uma caixa física. Ele registra qual conteúdo deve entrar no próximo commit. A lição de git init e primeiro commit mostra esse percurso com mudanças parciais.

Git local e GitHub remoto cumprem papéis diferentes

Até aqui não houve rede, token, SSH nem conta. Commit, log, branch, merge e restauração são funções locais. O GitHub recebe uma cópia do histórico e oferece pull requests, revisão, permissões, issues e automações. Outros serviços também hospedam Git; GitHub não é um requisito do formato.

Quando chegar a hora de compartilhar, você vai conectar um endereço com git remote e enviar commits com git push. A prática segura está em subir um projeto para um remoto. Neste material, os testes de rede usam um repositório bare local: ele prova push, fetch, pull e clone sem criar nem alterar um projeto externo.

O erro comum neste ponto é pensar que salvar no editor já cria uma versão. Não cria. Outro tropeço é apagar .git para “limpar” o projeto e descobrir que o histórico desapareceu. Antes de mexer nessa pasta, confira git status e faça uma cópia se ainda estiver aprendendo.

Sua missão é criar uma pasta temporária, inicializar o Git, adicionar dois arquivos e fazer dois commits com mensagens que expliquem resultados. Termine quando git log --oneline mostrar a ordem e você conseguir apontar working tree, stage e repositório sem confundir Git com GitHub. Depois, use o guia de Git e GitHub como mapa da sequência completa.