O que é Git e por que todo desenvolvedor precisa dele

Git é um sistema de controle de versão

Git é um programa que registra o histórico de alterações dos arquivos de um projeto. Toda vez que você registra o estado do código, o Git salva um snapshot (commit) com autor, data e descrição. Dá para voltar a qualquer snapshot, compará-lo com o estado atual e descobrir quem mudou uma linha específica e por quê.

Se você já teve pastas como «projeto_v2», «projeto_final» e «projeto_final_AGORA_VAI», você já fazia controle de versão — só que na mão. O Git faz a mesma coisa de forma automática, compacta e sem medo de perder nada. Por isso, quando desenvolvedores falam em Git, não estão falando de um programa qualquer, e sim de uma ferramenta básica de trabalho, tão obrigatória quanto o editor de código.

Qual a diferença entre Git, uma «pasta de cópias» e um drive na nuvem

Um drive na nuvem guarda a última versão do arquivo e, na melhor das hipóteses, algumas cópias automáticas. O Git guarda um histórico com significado: você decide quando registrar as alterações e escreve o que exatamente foi feito. Além disso, o Git faz coisas que nenhum drive faz:

• manter várias linhas de desenvolvimento ao mesmo tempo (branches) e mesclá-las;
• mostrar a diferença linha a linha entre versões (git diff);
• combinar as alterações de pessoas diferentes nos mesmos arquivos;
• encontrar o commit a partir do qual um bug apareceu (git bisect);
• funcionar sem internet — todo o histórico fica na sua máquina.

O significado do nome Git

Git não tem um significado oficial — não é uma sigla. Linus Torvalds batizou o programa no seu estilo: na gíria britânica, git é «um sujeito chato, teimoso». O próprio Torvalds brincava que dá a todos os seus projetos nomes em homenagem a si mesmo. Numa tradução livre, algo como «mala» ou «cabeça-dura».

No primeiro README do projeto, o autor sugeriu algumas expansões de brincadeira: por exemplo, «global information tracker» — quando tudo funciona — e uma versão com palavrão para quando dá pau. Então, se perguntarem numa entrevista «o que significa a sigla git», a resposta certa é: nada, é uma palavra, não um acrônimo.

Em português, todo mundo diz simplesmente «Git», com pronúncia «guit» (o g é duro, não «djit»).

De onde surgiu o Git

Até 2005, os desenvolvedores do kernel Linux usavam o sistema proprietário BitKeeper. Quando a licença gratuita para a comunidade foi revogada, Torvalds escreveu seu próprio sistema em poucas semanas. Os requisitos eram duros: velocidade em um projeto enorme, trabalho totalmente distribuído, proteção confiável do histórico contra corrupção e facilidade para lidar com milhares de branches em paralelo.

Pouco depois, Junio Hamano assumiu a manutenção do projeto e continua sendo o mantenedor do Git até hoje. Hoje o Git é um sistema aberto, sob licença GPLv2, e é a base de GitHub, GitLab, Bitbucket, Gitea e plataformas corporativas.

Como o Git funciona por dentro

Para que o Git deixe de parecer um monte de comandos mágicos, vale entender três ideias. Elas explicam quase todo o comportamento do sistema.

1. Snapshots, não diferenças

Muitos sistemas antigos guardavam as alterações como um conjunto de patches nos arquivos. O Git pensa em snapshots: cada commit é o estado completo do projeto no momento do registro. Para não desperdiçar espaço, arquivos sem alteração não são copiados: o commit simplesmente aponta para o objeto que já foi salvo. Ao compactar o repositório, o Git ainda comprime objetos parecidos, por isso o histórico até de um projeto grande ocupa pouco espaço.

2. Tudo é endereçado por hash

Cada objeto no Git — conteúdo de arquivo (blob), estrutura de pasta (tree), commit — recebe um identificador calculado a partir do seu conteúdo. Historicamente é SHA-1 (40 caracteres hexadecimais); nas versões novas dá para criar um repositório com SHA-256. É impossível alterar um commit antigo sem ninguém perceber: o hash dele e o de todos os commits seguintes mudariam.

$ git log --oneline -3
a3f9c21 Adicionar formulário de login
7b02e4d Corrigir validação de e-mail
1c8d5f0 Primeiro commit

As sequências curtas à esquerda são os hashes abreviados dos commits. Com eles você acessa qualquer versão: git show 7b02e4d.

3. Os três estados dos arquivos

Esse é o fundamento do Git, e cai em quase toda entrevista. Um arquivo do projeto pode estar em uma de três áreas:

O índice é o que diferencia o Git de muitos outros sistemas. Ele permite colocar no commit só parte das alterações: por exemplo, a correção de um bug separada da renomeação de variáveis. Assim o histórico fica legível.

Distribuído: por que cada um tem uma cópia completa

Git é um sistema de controle de versão distribuído (DVCS). Ao clonar, você recebe não só os arquivos mais recentes, mas todo o histórico do projeto. A maioria das operações — commit, ver o histórico, criar branch, comparar — é executada localmente e na hora, sem servidor.

Nesse modelo, um servidor como o GitHub é só mais uma cópia do repositório, que a equipe combinou de tratar como a principal. Se ele cair, o trabalho não para: você continua commitando e envia as alterações depois com git push. Se o servidor se perder de vez, o histórico pode ser restaurado a partir de qualquer clone.

Git e GitHub não são a mesma coisa

É uma confusão comum entre iniciantes. Git é o programa que roda no seu computador. GitHub é um serviço web onde ficam repositórios Git e onde há ferramentas para trabalho em equipe: pull request, code review, issues, CI. GitLab e Bitbucket são serviços equivalentes.

Dá para usar Git sem GitHub nenhum — por exemplo, para notas pessoais ou um projeto local. Já o GitHub sem Git não faz sentido: ele é construído em torno dos repositórios Git.

Fundamentos do Git: o ciclo mínimo de trabalho

É assim que fica o dia a dia. Esses poucos comandos cobrem a maior parte do que um desenvolvedor faz todos os dias.

# criar um repositório na pasta atual
git init

# ver o que mudou
git status

# adicionar arquivos ao índice
git add index.html style.css

# registrar o snapshot
git commit -m "Montar a página inicial"

# ver o histórico
git log --oneline

# criar uma branch e mudar para ela
git switch -c feature/login

# mesclar a branch na principal
git switch main
git merge feature/login

# enviar as alterações para o servidor
git push origin main

O comando git switch surgiu no Git 2.23 como substituto mais claro para parte das funções do git checkout. Em tutoriais antigos você vai ver git checkout -b feature/login — é a mesma coisa.

O que acontece no git commit

O Git pega o conteúdo do índice, salva cada arquivo como blob, monta objetos tree para as pastas e cria um objeto commit. No commit ficam registrados: a referência para a árvore, a referência para o commit pai (ou dois, depois de um merge), autor, committer e mensagem. Em seguida, o ponteiro da branch atual avança para o novo commit. Uma branch no Git é literalmente um arquivo com o hash do último commit, por isso branches são criadas em milissegundos.

Para que serve o Git na prática

Você perde o medo de experimentar

Qualquer alteração é reversível. Quebrou o código — git restore arquivo traz de volta a última versão registrada. Um commit ruim já está no histórico — git revert cria um commit inverso sem reescrever o histórico compartilhado. Isso muda o jeito de trabalhar: você arrisca mais, porque desfazer custa segundos.

Trabalho em equipe sem bagunça

Cada desenvolvedor trabalha na sua branch e não atrapalha os outros. Quando a tarefa fica pronta, as alterações passam por review e são mescladas na branch principal. Se duas pessoas mexeram no mesmo trecho, o Git mostra um conflito e deixa você resolvê-lo conscientemente, em vez de sobrescrever o trabalho alheio em silêncio.

Histórico como documentação

Boas mensagens de commit respondem à pergunta «por que o código está assim». O comando git blame arquivo mostra quem alterou cada linha por último e em qual commit, e git log -p arquivo mostra toda a evolução do arquivo. Um ano depois, isso economiza horas de investigação.

Exigência do mercado

Conhecimento de Git aparece em praticamente toda vaga de desenvolvedor, QA, engenheiro DevOps e analista de dados. Na entrevista, o que se avalia não é decoreba de comandos, e sim entendimento: a diferença entre merge e rebase, o que é o índice, como desfazer um commit, como resolver um conflito. E um perfil no GitHub com um histórico de commits caprichado funciona como portfólio.

Quem mais precisa de Git

O Git é útil em qualquer lugar onde há arquivos de texto e o histórico importa: redatores técnicos (documentação em Markdown), quem faz front-end e layout, analistas (scripts SQL, notebooks), administradores de sistemas (configuração de servidores, infraestrutura como código). Para arquivos binários grandes — vídeo, PSD, datasets — usa-se a extensão Git LFS, porque o Git em si é otimizado para texto.

Pro Git — o melhor livro sobre Git

Se quiser se aprofundar, comece pelo livro «Pro Git», de Scott Chacon e Ben Straub. Ele é gratuito, distribuído sob licença aberta e publicado no site oficial git-scm.com, na seção Book, inclusive com tradução para o português. É o tal «pro git» que tanta gente procura: um manual completo, dos fundamentos ao funcionamento interno.

Como ler com proveito:

• capítulos 1–3 (introdução, fundamentos, branches) — o mínimo obrigatório; repita os comandos no terminal;
• o capítulo sobre repositórios remotos e GitHub — quando começar a trabalhar em equipe;
• o capítulo «Git Internals» — quando quiser entender de verdade como funcionam objetos e referências.

O segundo apoio oficial é a ajuda embutida: git help commit ou git commit --help abrem a documentação completa do comando, e git commit -h mostra um resumo das flags.

Equívocos comuns de iniciantes

• «O Git salva os arquivos automaticamente». Não: até você fazer um commit, as alterações existem só no diretório de trabalho.
• «O commit vai direto para o GitHub». O commit é local. Ele só vai para o servidor depois do git push.
• «git add é só para arquivos novos». O git add também adiciona ao índice as alterações de arquivos já rastreados.
• «O que saiu do histórico não volta mais». Quase sempre volta: o git reflog guarda os movimentos dos ponteiros, e o commit «perdido» é encontrado pelo hash.
• «Branches são cópias do projeto». Uma branch é um ponteiro leve para um commit, não uma duplicata dos arquivos.

Por onde começar a estudar

1. Instale o Git e confira a versão: git --version.
2. Configure nome e e-mail: git config --global user.name e user.email.
3. Crie um repositório de estudo, faça de 5 a 10 commits, olhe o git log e o git diff.
4. Pratique com branches: crie, mescle, provoque um conflito de propósito e resolva.
5. Crie uma conta no GitHub, envie o repositório para lá e abra seu primeiro pull request.

Essa sequência dá resultado mais rápido do que ler manuais de ponta a ponta: você vê na hora como cada comando muda o estado do repositório.

Resumo

Git é um sistema de controle de versão distribuído que guarda o histórico do projeto em snapshots, protege esse histórico com hashes e permite que a equipe trabalhe em paralelo em branches. O nome não é sigla, e na prática Git é ferramenta obrigatória de qualquer desenvolvedor. Domine o ciclo add — commit — push, entenda as três áreas dos arquivos e as branches e depois se aprofunde com o livro Pro Git. Tudo isso, passo a passo, do primeiro commit ao pull request, é trabalhado na prática no curso de Git.