Como aprender Git: plano de estudo, simuladores, documentação e prática

Git se aprende com a mão na massa, não lendo. Para trabalhar com segurança em equipe, basta dominar umas vinte comandos e entender três ideias: commit é um retrato do projeto, branch é um ponteiro para um commit, e o repositório remoto é apenas mais uma cópia do histórico. Abaixo está um plano de estudo do Git por etapas, com exercícios, recursos gratuitos e critérios para saber quando cada etapa está concluída.

O plano foi pensado para quem está começando e já sabe usar o terminal pelo menos no nível de cd e ls. Se ainda não sabe, reserve uma noite para os fundamentos da linha de comando: sem isso, estudar Git fica bem mais difícil.

Por que vale estudar Git de forma sistemática

Muita gente usa o Git há anos com cinco comandos copiados de um tutorial e entra em pânico com o primeiro conflito ou com o «detached HEAD». Quase sempre o motivo é o mesmo: falta um modelo mental, ou seja, a pessoa não sabe o que cada comando altera no histórico e nos arquivos.

Estudar Git de forma organizada compensa rápido. Você deixa de ter medo de experimentar, porque sabe como desfazer uma mudança; resolve conflitos com calma; e mantém um histórico limpo, que revisores e recrutadores costumam olhar. Git aparece em entrevistas em praticamente todas as áreas de TI, de front-end a DevOps e análise de dados.

Etapa 1. Fundamentos: repositório, índice e commit

O objetivo da primeira etapa é entender o ciclo básico e as três áreas do Git: o diretório de trabalho, o índice (staging area) e o repositório. Leva de 2 a 4 dias, com cerca de uma hora por dia.

• Instalação e configuração inicial: git config --global user.name, user.email, branch padrão main.
• Criação de um repositório: git init.
• O ciclo git status → git add → git commit; adição seletiva com git add -p.
• Visualizar o histórico: git log --oneline, git diff, git diff --staged, git show.
• O arquivo .gitignore: o que não deve entrar no repositório.

Exercício. Crie um repositório para anotações pessoais ou para um pequeno script. Faça de 15 a 20 commits, cada um com uma única mudança lógica e uma mensagem clara. Depois de cada comando, rode git status e explique para si mesmo o que mudou.

Etapa concluída quando você consegue, sem ajuda, dizer em que a saída de git diff difere de git diff --staged e fazer um commit com apenas parte dos arquivos alterados.

Etapa 2. Branches e merge

Branches são o coração do Git e a principal fonte de medo para quem está começando. Aqui o importante não é decorar comandos, e sim aprender a imaginar o grafo de commits. Reserve cerca de uma semana para esta etapa.

• Criar e trocar de branch: git branch, git switch, git switch -c.
• O que é o HEAD e o estado de detached HEAD.
• Merge: git merge, fast-forward e merge commit, a flag --no-ff.
• Conflitos: os marcadores <<<<<<< e >>>>>>>, e git merge --abort.
• Visualização: git log --oneline --graph --all.

Exercício. Crie duas branches a partir da main e altere a mesma linha de um mesmo arquivo em cada uma. Faça o merge delas uma por vez, provoque o conflito e resolva. Repita até o processo ficar tranquilo.

Nesta etapa, o que mais ajuda é um simulador interativo de Git, que mostra o grafo depois de cada comando e constrói intuição rapidamente. Falo sobre eles mais abaixo.

Etapa 3. Repositórios remotos e trabalho em equipe

O objetivo é aprender a trabalhar com o servidor do jeito que as equipes fazem. Você vai precisar de uma conta no GitHub, no GitLab ou em outro serviço de hospedagem Git. Duração: cerca de uma semana.

• Conectar e clonar: git remote add, git clone, login com chave SSH.
• Sincronização: git push, git push -u, git fetch, git pull e a diferença entre eles.
• Branches de rastreamento remoto, como origin/main.
• Forks, branches de funcionalidade e pull request com code review.
• Processos de equipe: GitHub Flow, Git Flow, trunk-based development.

Exercício. Trabalhe com um mesmo repositório a partir de dois «computadores»: clone-o em duas pastas diferentes. Faça commits em uma, dê push, traga as mudanças para a outra. Crie uma situação em que o push é rejeitado porque o servidor já avançou, e entenda por quê.

git clone git@github.com:voce/sandbox.git copia-a
git clone git@github.com:voce/sandbox.git copia-b
cd copia-a && echo "vindo de A" >> notas.txt && git commit -am "Ajuste vindo de A" && git push
cd ../copia-b && echo "vindo de B" >> notas.txt && git commit -am "Ajuste vindo de B"
git push          # rejected: o servidor avançou
git pull          # traz o ajuste de A, resolva o conflito em notas.txt
git push

Este roteiro curto reproduz a situação mais comum em equipe. Analise a saída de cada comando: por que o push foi rejeitado, o que apareceu em origin/main depois do fetch, de onde veio o merge commit. Depois repita o mesmo com git pull --rebase e compare os grafos com git log --oneline --graph --all.

Melhor ainda: encontre um colega e façam juntos um pequeno projeto com pull requests. Assim você sente na prática a revisão de código, os conflitos e os acordos sobre branches.

Etapa 4. Desfazer erros

Esta etapa transforma o Git de fonte de ansiedade em uma rede de segurança. Leva de 3 a 5 dias.

• git restore e git restore --staged: desfazer mudanças nos arquivos e no índice.
• git commit --amend: corrigir o último commit.
• git reset nos modos --soft, --mixed e --hard.
• git revert: desfazer com segurança um commit já publicado.
• git reflog: recuperar commits «perdidos».

Exercício. Faça alguns commits, rode git reset --hard HEAD~3 e recupere-os pelo reflog. Desfaça um commit em uma branch «compartilhada» com revert e veja como isso aparece no histórico.

Etapa 5. Ferramentas avançadas

Estas ferramentas são aprendidas conforme a necessidade, mas vale saber que existem desde cedo.

Simuladores de Git: onde praticar

Um simulador é útil porque oferece uma caixa de areia segura e mostra o resultado na hora. Algumas opções gratuitas:

• Learn Git Branching (learngitbranching.js.org): o melhor simulador focado em branches. Tem fases com desafios e um grafo de commits animado. Cobre commit, branch, merge, rebase, cherry-pick, rebase interativo e trabalho com remotos.
• Oh My Git!: jogo gratuito e de código aberto em que os comandos do Git são representados por cartas, e por trás funciona um Git de verdade.
• Um repositório-sandbox próprio: subestimado, mas muito útil. Crie uma pasta git-sandbox e quebre tudo nela, sem medo, porque não há nada a perder.

Os simuladores são ótimos para entender o grafo, mas não substituem um projeto real: não há arquivos de verdade, editor, conflitos em código de verdade nem IDE. Use-os como complemento.

Documentação oficial e livros

A documentação oficial do Git fica em git-scm.com. Lá também está, gratuitamente, o livro Pro Git, de Scott Chacon e Ben Straub, que tem tradução para o português (versão pt-BR). É o melhor livro sobre Git: os três primeiros capítulos (fundamentos e branches) são obrigatórios, e o capítulo «Git por dentro» é para quem quer entender o modelo de dados até o fim.

A ajuda embutida está sempre à mão: git help <comando> abre o manual completo, e git <comando> -h mostra um resumo das flags. A documentação do Git é seca, mas precisa; crie o hábito de consultá-la em vez de confiar na primeira resposta da busca.

git help rebase        # manual completo
git switch -h          # resumo das flags
git help -g            # lista de guias conceituais (gitworkflows, gittutorial…)

Vale ler também os guias gittutorial e giteveryday. Eles acompanham o Git e abrem com git help.

Estudar sozinho ou fazer um curso

É perfeitamente possível aprender Git sozinho: livro, simulador e sandbox dão tudo o que é necessário. A dificuldade está em outro ponto: sem estrutura, é fácil ficar preso na teoria ou, ao contrário, juntar comandos sem entender, e sem retorno ninguém vai dizer que você está deixando o histórico bagunçado.

Um curso de Git ajuda se você quer percorrer o caminho de forma rápida e em ordem: do primeiro commit até um pull request em um repositório real, com tarefas em cada passo. Ao escolher, não olhe apenas a duração, e sim a proporção de prática: há exercícios com conflitos, desfazer erros, trabalho em equipe e um projeto final?

Quanto tempo leva para aprender Git

Os números são aproximados: o que decide é a regularidade. Uma hora por dia rende mais do que maratonas de fim de semana uma vez por mês.

Erros comuns ao estudar Git

• Aprender só pela interface gráfica. Clientes gráficos são práticos, mas escondem o modelo. Entenda primeiro a linha de comando e depois escolha a ferramenta que preferir.
• Decorar flags. O importante é entender as ideias; as flags sempre estão disponíveis em -h.
• Ter medo de quebrar. Enquanto você não fez um reset --hard e se recuperou, não sabe que o Git está protegendo você.
• Pular os repositórios remotos. Git local sem push, pull e pull request é só metade da habilidade.
• Commits chamados «fix» e «update». É mais fácil criar o hábito de escrever mensagens claras desde o início.

Projeto final para fixar o conteúdo

A melhor prova é simular um desenvolvimento em equipe. Crie um repositório, proteja a branch main contra push direto, convide um colega ou trabalhe com duas contas. Cada tarefa vira uma branch de funcionalidade e um pull request com revisão; pelo menos uma vez provoque um conflito, pelo menos uma vez desfaça um commit ruim com revert, e marque uma release com uma tag.

Depois de um projeto assim, o Git deixa de ser um conjunto de feitiços. Você enxerga o grafo, entende as consequências de cada comando e está pronto para as perguntas de entrevista.

Resumo

Aprender Git funciona melhor em ordem: ciclo básico, branches, trabalho com o servidor, desfazer erros e, por fim, ferramentas avançadas. O simulador ajuda a enxergar o grafo, o Pro Git e a documentação oficial dão profundidade, e a sua própria sandbox e um projeto em equipe transformam o conhecimento em habilidade. É esse caminho, do git init até o pull request do projeto final, que o nosso curso de Git percorre, com prática em cada passo.