O que é Git: o guia completo do controle de versão que domina o mundo do software

Git é o sistema de controle de versão mais popular do mundo: uma ferramenta que registra, ao longo do tempo, todas as alterações feitas nos arquivos de um projeto e guarda esse histórico num banco de dados especial chamado repositório. Com ele, você consulta quem mudou o quê, quando e por quê, e — se algo der errado — volta o projeto para um estado anterior sem drama. Criado em 2005 por Linus Torvalds, o mesmo sujeito por trás do Linux, o Git se tornou a espinha dorsal do desenvolvimento de software moderno. Estima-se que mais de 90% dos projetos de software no mundo o utilizem, e é por isso que praticamente toda vaga de desenvolvedor pede Git como requisito. Neste guia, você vai entender o que é o Git, como ele funciona e por que virou item obrigatório na caixa de ferramentas de quem programa.

Antes do Git: o que é controle de versão

Para entender o Git, é preciso primeiro entender o problema que ele resolve. Um sistema de controle de versão (ou VCS, de version control system) é um mecanismo que rastreia as alterações feitas em um conjunto de arquivos ao longo do tempo. Uma analogia que funciona bem é a do videogame: você tem pontos de salvamento e, a qualquer momento, pode voltar para um deles e continuar dali. O controle de versão faz exatamente isso, só que com o seu código em vez de uma fase de jogo. Ele captura instantâneos (os famosos snapshots) das mudanças que você faz, um atrás do outro.

Pense no seu currículo. Se você é como a maioria das pessoas, deve ter por aí um "currículo_v2", um "currículo_v3", um "currículo_final" e — por que não — um "currículo_final_MESMO". São quatro arquivos quase idênticos ocupando espaço e gerando confusão. Com um sistema de controle de versão, você mantém um único arquivo, porque o próprio sistema guarda todas as versões anteriores e o histórico completo das mudanças. Você pode revisar cada alteração e resgatar qualquer versão passada sem precisar duplicar nada.

No desenvolvimento de software, o benefício é ainda mais evidente. Sem controle de versão, a equipe teria que ficar salvando cópias do projeto inteiro em pastas diferentes, trocando o código mais recente por e-mail e mesclando alterações na mão. É lento, é frágil e não escala — especialmente quando várias pessoas trabalham no mesmo projeto ao mesmo tempo. Um VCS resolve isso de duas formas de uma vez: rastreia o histórico e permite a colaboração.

Em resumo, um bom sistema de controle de versão oferece três superpoderes:

• Histórico completo: você visualiza todas as alterações já feitas e sabe exatamente quando cada uma entrou.
• Desfazer com segurança: se você errou uma semana, um mês ou um ano atrás, dá para reverter para qualquer ponto anterior.
• Colaboração: várias pessoas trabalham no mesmo projeto sem sobrescrever o trabalho umas das outras.

Centralizado x distribuído: onde o Git brilha

Os sistemas de controle de versão se dividem em duas grandes categorias, e entender essa diferença é a chave para sacar por que o Git é especial.

Nos sistemas centralizados, existe um servidor central que guarda o código. Todos os membros da equipe se conectam a esse servidor para pegar a versão mais recente e enviar suas mudanças. O Subversion (SVN) e o Microsoft Team Foundation Server são exemplos clássicos. O problema dessa arquitetura é o ponto único de falha: se o servidor central cai, ninguém consegue colaborar nem salvar um snapshot do trabalho. Fica todo mundo de mãos atadas esperando o servidor voltar.

Nos sistemas distribuídos, esse gargalo simplesmente não existe. Cada pessoa da equipe tem uma cópia completa do projeto, com todo o histórico, na própria máquina. Isso significa que você salva snapshots localmente, trabalha offline e, se o servidor central estiver fora do ar, ainda consegue sincronizar diretamente com os colegas. O Git e o Mercurial são exemplos de sistemas distribuídos — e o Git é, disparado, o mais usado.

Foi justamente essa a motivação por trás do Git. Linus Torvalds o criou em 2005 porque enfrentava problemas com o BitKeeper, a ferramenta de controle de versão usada até então no desenvolvimento do software livre que é o kernel Linux. O Git introduziu o controle de versão distribuído de um jeito que permitia a muitos desenvolvedores trabalharem no mesmo projeto simultaneamente, sem os conflitos e as limitações que atrapalhavam antes.

Por que o Git é tão popular

Ser distribuído é ótimo, mas não explica sozinho por que o Git engoliu o mercado. Alguns fatores pesaram bastante:

• É gratuito e de código aberto. Qualquer pessoa pode baixar, usar e estudar o Git sem pagar nada.
• É extremamente rápido e escalável. Operações como criar ramificações e mesclar código, que são lentas e trabalhosas em ferramentas como Subversion e TFS, acontecem quase instantaneamente no Git. Ele também lida muito bem com projetos e bases de código gigantes.
• Está em todo lugar. Como mais de 90% dos projetos de software usam Git, conhecê-lo deixou de ser diferencial e passou a ser pré-requisito. macOS e Linux, aliás, já vêm com uma versão do Git pré-instalada; no Windows você precisa baixá-lo, mas a instalação é simples.
• Documentação e comunidade enormes. Qualquer problema que você encontrar provavelmente já foi resolvido e documentado por outra pessoa. Uma busca rápida costuma bastar.
• Integra com tudo. O Git conversa com plataformas e ferramentas como GitHub, GitLab, SourceTree, Heroku e muitas outras.

E não pense que Git é coisa só de quem programa sistemas. Times de ciência de dados, engenharia de dados e várias outras áreas adotaram a ferramenta no dia a dia. Onde há arquivos que mudam ao longo do tempo e gente colaborando, o Git tende a aparecer.

Os conceitos fundamentais do Git

Aqui é onde a coisa fica prática. O Git tem um vocabulário próprio, e dominar esses termos é meio caminho andado. Vamos por partes.

Repositório

O repositório é onde o Git guarda o histórico do seu projeto. Quando você inicializa o Git numa pasta, ele cria um diretório oculto — o .git — que fica ali dentro registrando cada alteração dos arquivos. Esse é o primeiro comando que você roda num projeto novo: git init, que cria um repositório local e faz o Git começar a rastrear as mudanças. É comum ter um repositório local (na sua máquina) e um repositório remoto (hospedado na internet ou numa rede), que permite a colaboração entre várias pessoas.

Diretório de trabalho e área de preparação

O diretório de trabalho é o seu espaço de trabalho: contém o estado atual dos arquivos do projeto, incluindo as mudanças que o Git ainda não foi instruído a rastrear. Antes de gravar uma alteração no histórico, você a coloca na área de preparação (também chamada de staging ou índice). Pense nela como um rascunho: é onde você seleciona e revisa exatamente o que vai entrar no próximo snapshot, antes que aquilo vire parte permanente do histórico. Você move arquivos para a área de preparação com git add.

Esse passo intermediário parece burocracia, mas é uma das sacadas do Git: ele deixa você montar cada snapshot com cuidado, incluindo só as mudanças que fazem sentido guardar juntas.

Commit

O commit é o instantâneo em si — a fotografia do estado dos seus arquivos naquele momento. Depois de preparar as mudanças com git add, você executa git commit junto com uma mensagem descrevendo o que foi feito. Cada commit recebe um identificador único e aponta para o commit anterior (o "pai"), formando uma corrente. É essa corrente que permite viajar no tempo pelo seu projeto e voltar a qualquer versão anterior.

Existe ainda o conceito de HEAD, que é simplesmente uma referência ao commit mais recente em que você está. Cada novo commit faz o HEAD avançar, mas as referências aos commits antigos continuam ali, sempre acessíveis. No fluxo do dia a dia, o trio git status, git add e git commit é o que você mais vai usar — vale praticar até virar reflexo.

Branch (ramificação)

O software raramente é desenvolvido de forma linear. Várias equipes podem trabalhar em funcionalidades diferentes da mesma base de código ao mesmo tempo, e é aí que entram as branches, ou ramificações. Uma branch é como uma linha do tempo alternativa: um universo paralelo onde você constrói, corrige bugs e experimenta com segurança, sem afetar o código principal.

Normalmente existe uma branch principal — historicamente chamada de master, hoje mais comumente main — que funciona como a "fonte da verdade" do projeto. A partir dela, você cria uma nova branch (git branch) e entra nela (git checkout) para trabalhar isolado. Os commits que você faz ali vivem no seu universo alternativo, com histórico próprio, sem tocar na branch principal. Se algo der errado, o resto do time nem fica sabendo.

Merge (mesclagem)

Cedo ou tarde, você vai querer trazer o trabalho daquela branch de volta para a linha principal. Esse processo se chama merge, ou mesclagem: integrar as alterações de uma branch em outra, combinando os dois históricos num só. Na prática, você volta para a branch principal com git checkout e executa git merge apontando para a branch da funcionalidade. Os universos paralelos voltam a ser um só.

Na maior parte das vezes isso acontece sem sustos. Mas quando duas pessoas mexem na mesma parte do mesmo arquivo de formas incompatíveis, surge um conflito de merge — e aí o Git para e pede que um humano decida qual versão prevalece. Conflitos assustam os iniciantes, mas fazem parte da rotina e se resolvem com calma.

Um fluxo de trabalho típico com Git

Juntando as peças, um dia comum de trabalho com Git costuma seguir mais ou menos este roteiro:

1. Você inicializa um repositório com git init (ou clona um existente com git clone).
2. Faz alterações nos arquivos, no seu diretório de trabalho.
3. Verifica o que mudou com git status.
4. Move as mudanças para a área de preparação com git add.
5. Grava um snapshot com git commit e uma mensagem descritiva.
6. Cria branches para novas funcionalidades e as mescla de volta com git merge quando prontas.
7. Sincroniza tudo com um repositório remoto, enviando e recebendo alterações.

Antes de começar, aliás, vale configurar quem você é. Comandos como git config --global user.name e git config --global user.email informam ao Git o seu nome e e-mail, para que cada commit fique creditado a você. É um passo rápido, feito uma vez, e evita commits "anônimos".

Git não é GitHub: entenda a diferença

Essa é provavelmente a confusão mais comum entre iniciantes, então vamos ser diretos: Git e GitHub não são a mesma coisa — e nem pertencem à mesma empresa. O Git é o software, a ferramenta de linha de comando que roda na sua máquina e gerencia o controle de versão. O GitHub é um serviço: uma plataforma na nuvem que hospeda repositórios Git e adiciona uma camada de recursos por cima.

O GitHub foi fundado em 2008 e rapidamente se tornou um dos maiores sites de hospedagem de código do mundo. Em 2018, foi adquirido pela Microsoft por mais de 7 bilhões de dólares — um bom termômetro do valor que a plataforma acumulou. Ele é construído sobre o Git: usa o Git por baixo para rastrear as versões, e por cima oferece interface gráfica, revisão de código, planejamento de projetos, automação, CI/CD, recursos de segurança e ferramentas de colaboração. GitLab e outros serviços seguem a mesma ideia.

As diferenças, resumidas:

• Git é o sistema de controle de versão; GitHub é um serviço de hospedagem para repositórios Git.
• Git roda localmente, na sua máquina; GitHub fica na nuvem, acessível de qualquer lugar.
• Git é uma ferramenta de linha de comando; GitHub oferece uma interface gráfica amigável.
• Git é mantido pela comunidade do software livre; GitHub pertence à Microsoft.

Na prática, você usa o Git o tempo todo enquanto programa na sua máquina local. Quando quer salvar aquilo em segurança, acessar de outro computador ou compartilhar com o time, você conecta seu repositório a uma plataforma como o GitHub. Outras pessoas podem então clonar o repositório, contribuir e propor mudanças. É aí que entra o pull request: uma forma de propor a integração das alterações de uma branch em outra, abrindo espaço para revisar, discutir e, se tudo estiver certo, mesclar. É o coração da colaboração em equipe no dia a dia.

Vale a pena aprender Git?

Sem rodeios: sim. O Git deixou de ser um detalhe técnico e virou uma habilidade fundamental para qualquer pessoa que trabalhe com código — e, cada vez mais, para quem trabalha com dados, documentação e outros arquivos que evoluem com o tempo. Quase toda descrição de vaga para desenvolvedor menciona Git, e dominá-lo de verdade (entender como funciona, não só decorar comandos) faz diferença real na carreira.

A boa notícia é que a barreira de entrada é baixa. O Git é gratuito, está bem documentado e roda em qualquer sistema operacional. Você pode começar hoje: instale a ferramenta, configure seu nome e e-mail, crie uma pasta de testes e brinque com git init, git add, git commit e git status até esses comandos entrarem no automático. A linha de comando pode intimidar no começo, mas é muito mais simples do que parece — e, uma vez que você pega o jeito, não vai querer mais viver sem controle de versão. Aquele "currículo_final_MESMO" agradece.