Git — Visão Geral

O git é um sistema de controle de versão. Em uma frase: ele tira fotos do seu projeto a cada commit e guarda essas fotos numa linha do tempo. Você pode voltar pra qualquer foto, comparar duas, criar linhas paralelas pra experimentar, e sincronizar tudo entre máquinas. Esse card abre o mini-curso explicando o problema que motivou a criação do git, quem o criou, a ideia central e os três conceitos que sustentam tudo o que vem depois.

O problema — antes do git existir

Imagina trabalhar num projeto sozinho, sem versionamento. Você tem uma pasta projeto. De vez em quando dá medo de mexer e perder o que tá funcionando, então copia a pasta inteira: projeto-v1, projeto-v2, projeto-final, projeto-final-DE-VERDADE, projeto-final-DE-VERDADE-mesmo.

Quem nunca? Esse modelo quebra por três motivos óbvios:

• Espaço em disco — cada cópia é o projeto inteiro duplicado. Em projetos grandes (com vídeos, PDFs, dependências) isso vira gigabytes em pouco tempo.
• Sem histórico real — você sabe que tem 5 cópias, mas não sabe o que mudou entre uma e outra. Pra descobrir, precisa abrir as duas pastas e comparar arquivo por arquivo.
• Não escala pra mais de uma pessoa — se um colega entra, vocês começam a mandar pasta zipada por e-mail. Quem tá com a versão certa? Quem mexeu no quê? Em uma semana, vira caos.

Pior ainda: se você trabalha em duas máquinas (PC do escritório + notebook em casa), está sempre se perguntando "qual delas tem a versão mais nova?". Não tem fonte da verdade.

Quem criou e por quê

O git foi criado por Linus Torvalds em 2005 — o mesmo cara que criou o Linux. Ele não criou o git "pra ser ferramenta da indústria" — criou pra resolver um problema bem específico: versionar o kernel do Linux.

O drama do BitKeeper. Até 2005, os desenvolvedores do kernel usavam um sistema chamado BitKeeper. Era proprietário (pago) mas a empresa tinha liberado licença grátis pros devs do kernel. Em 2005, depois de uma briga (outro dev tentou fazer engenharia reversa do protocolo), a empresa cortou a licença grátis. De um dia pro outro, o projeto Linux ficou sem ferramenta de versionamento.

10 dias. Linus começou a escrever o git em 3 de abril de 2005. Em poucos dias já tinha o básico funcionando, e em duas semanas o próprio kernel do Linux já estava sendo versionado nele. O nome "git" é gíria britânica pra "cara desagradável" — Linus brincou que era um sistema "tão simples que beira a estupidez". Brincadeira só, ele construiu um sistema bastante sofisticado por dentro.

Os requisitos do Linus. Ele tinha critérios bem claros sobre o que precisava do novo sistema:

• Rápido — o kernel tem milhões de linhas. Comandos como ver histórico ou fazer commit precisavam ser instantâneos.
• Distribuído — cada desenvolvedor deveria ter uma cópia completa do repositório, com histórico inteiro, sem depender de um servidor central. Isso permite trabalhar offline e elimina ponto único de falha.
• Branches baratas — criar uma linha do tempo paralela tinha que ser questão de milissegundos, pra incentivar experimentação.
• Robusto contra corrupção — toda foto guardada tem uma assinatura criptográfica (hash). Se um byte é alterado, o git detecta.

Por que virou padrão de mercado. Antes do git, o mundo usava sistemas como CVS e SVN — todos centralizados (precisavam de servidor pra commitar). Git inverteu o modelo: é distribuído, todo mundo tem o repositório completo. Em 2008 nasceu o GitHub — um site pra hospedar repositórios git e facilitar colaboração — e a combinação git + GitHub virou padrão de mercado em poucos anos. Hoje, é praticamente impossível trabalhar com código profissionalmente sem git.

A ideia do git — snapshots

A grande sacada do git é tratar versionamento como uma sequência de fotos (snapshots) do projeto inteiro.

Toda vez que você marca um ponto importante no trabalho (fez uma alteração, ajeitou um bug, terminou uma feature), o git tira uma foto do estado atual de todos os arquivos e guarda numa linha do tempo. Cada foto leva uma mensagem sua descrevendo o que foi feito, mais o seu nome e a data.

O que você ganha com isso:

• Voltar atrás — quebrou alguma coisa? Volta na foto anterior, vê o que estava funcionando, descobre o que mudou.
• Comparar duas fotos — o que mudou entre ontem e hoje? Entre a versão 1.0 e a 2.0? O git mostra arquivo por arquivo, linha por linha.
• Histórico explorável — em vez de "tinha uma pasta projeto-final2 mas não lembro o que mudou", você lê uma lista de mensagens descrevendo cada passo do projeto.
• Compartilhamento controlado — quando manda o repositório pra outra pessoa, ela recebe a linha do tempo inteira, não só o estado atual.

Detalhe técnico: o git é esperto e não duplica os arquivos que não mudaram entre uma foto e outra. Ele guarda só as diferenças por baixo, mesmo que você "veja" cada foto como um snapshot completo. Isso é o que mantém o repositório leve mesmo com milhares de commits.

Os 3 conceitos centrais

Antes de mexer em qualquer comando, três conceitos sustentam tudo o que o git faz:

Repositório

Um repositório é a sua pasta de projeto + a história dela. Quando você "transforma uma pasta em repositório git" (com o comando git init, que vem nos próximos cards), o git cria uma subpasta oculta chamada .git dentro dela. Essa pasta .git guarda todas as fotos, mensagens, autores, datas, branches — todo o histórico do projeto desde sempre.

Ponto importante: você não precisa mexer dentro da .git. Os comandos do git é que escrevem e leem dali. Se você apagar a .git, perde o histórico inteiro mas os arquivos do projeto continuam intactos — vira uma pasta normal de novo.

Commit

Um commit é uma foto guardada na linha do tempo. Cada commit tem:

• Snapshot dos arquivos — o estado completo de todos os arquivos do projeto naquele momento.
• Mensagem — texto curto que você escreve descrevendo o que mudou ("ajusta validação do formulário", "adiciona tela de cadastro de produto").
• Autor — seu nome e e-mail, configurados uma vez na sua máquina.
• Data e hora — quando o commit foi feito.
• Hash — um identificador único de 40 caracteres (tipo 3f8a9c2...) gerado automaticamente. É o "número de série" daquela foto. Dois commits nunca têm o mesmo hash.
• Pai — referência ao commit anterior (a "foto" que veio antes). É isso que cria a linha do tempo encadeada.

O histórico do projeto inteiro é uma corrente de commits, cada um apontando pro pai. Pra ler a história, o git percorre essa corrente do mais novo pro mais antigo.

Branch

Uma branch (literalmente "galho", ou "ramo") é uma linha do tempo paralela. A ideia: quero experimentar uma alteração maluca sem mexer no que tá funcionando. Crio uma branch nova, faço meus commits ali, testo. Se ficou bom, junto (faço merge) com a linha principal. Se não ficou, descarto e nada se perde.

Toda repositório git começa com uma branch chamada main (antigamente master) — é o tronco principal. A partir dela, você cria outras: feature/login, fix/bug-123, experimento-novo. Cada uma é uma linha do tempo independente que pode ser combinada com as outras quando você quiser.

No XT especificamente, o projeto usa duas branches: dev (onde o trabalho do dia acontece) e main (a versão limpa, com histórico em squash). Esse fluxo aparece em detalhe no último card do mini-curso.

Local versus remoto

O git é distribuído: não existe "o repositório original" e "as cópias". Toda cópia é completa e equivalente.

Na prática, você tem dois lugares onde o repositório vive:

• Local — a cópia na sua máquina. É onde você faz commits, cria branches, vê histórico, edita arquivos. Funciona offline. Tem a história inteira do projeto na sua .git.
• Remoto — uma cópia hospedada num servidor (geralmente GitHub, mas existem outros: GitLab, Bitbucket, Gitea, e até servidores próprios). Serve pra backup e colaboração. Outros desenvolvedores acessam o remoto pra trabalhar no mesmo projeto.

Os dois canais que conectam local e remoto:

• push — manda os commits que estão só no seu local pro remoto. Sincroniza pra cima.
• pull — traz os commits que estão no remoto e ainda não chegaram no seu local. Sincroniza pra baixo.

Se você trabalha em duas máquinas (PC + notebook), o fluxo natural vira: commit no PC → push pro GitHub → ir pro notebook → pull do GitHub → continuar de onde parou. O GitHub vira o ponto de encontro entre as suas duas cópias locais.

O GitHub não é o git. Git é a ferramenta (programa instalado na sua máquina), GitHub é um site que hospeda repositórios git. Você pode usar git sem nunca usar GitHub (versionamento puramente local), e em teoria o GitHub poderia desaparecer amanhã que o seu repositório local continuaria funcionando. Na prática, todo projeto sério usa um remoto pra não perder tudo se a máquina queimar.

Por que aprender git

Quatro motivos diretos:

• Backup automático com histórico. Cada push pro GitHub é uma cópia de segurança remota da sua linha do tempo inteira. Se a máquina queimar, basta clonar o repositório em outra e continuar de onde parou.
• Voltar atrás sem medo. Quebrou tudo e não consegue ver o que mudou? Volta no commit anterior, compara, descobre o erro. Não precisa mais ter pasta-de-segurança copiada antes de mexer.
• Experimentar sem quebrar. Cria uma branch, testa uma ideia, se não rolou descarta. A linha principal (main) nunca quebra.
• Trabalhar com outras pessoas. Cada um faz seus commits, cada um faz push, o git sabe juntar as alterações. Quando dois mexem no mesmo lugar (conflito), o git avisa e você resolve manualmente. Sem mais arquivos zipados por e-mail.

Bônus: praticamente todo projeto open-source do mundo está hospedado no GitHub. Saber git é o que te permite ler o código de qualquer biblioteca que você usa, ver o histórico de mudanças, abrir issues, contribuir com pull requests. É uma linguagem comum da indústria.

O que vem nos próximos cards

Esse card foi só conceito — sem nenhum comando. Os próximos cards do mini-curso entram nos comandos práticos, seguindo a jornada de quem está começando do zero: setup do git, primeiro commit, histórico, compartilhamento via GitHub, branches, merge, conflitos, desfazer, reescrever histórico, e por fim o fluxo do XT com os 16 passos do /commit. Cada card é uma estação dessa jornada.

O grid do mini-curso (a página GIT no menu lateral) lista os cards conforme eles forem sendo criados. Volta lá pra ver o roadmap atual.