Git Avançado: Guia Prático para Aprender em 30 Dias

Você domina git add, git commit e git push. Sabe resolver conflitos básicos. Agora quer controlar o histórico com precisão cirúrgica, reverter sem medo, encontrar bugs com método científico e colaborar sem ruído. Git avançado não é sobre mais comandos, é sobre entender o grafo de commits como um sistema de versões que você pode editar, reorganizar e depurar.

Este plano de 30 dias pressupõe que você já usa Git no dia a dia. Cada semana foca um pilar: reescrita de histórico, navegação cirúrgica, debugging e workflows de equipe. O resultado esperado ao final: você consegue limpar um histórico bagunçado, aplicar apenas os commits que interessam, achar a origem de um bug em minutos e escolher o fluxo certo para cada projeto.

Passo 1: Semana 1, Reescrever o histórico com rebase interativo

Rebase interativo (git rebase -i) é a ferramenta mais subestimada por quem só aprendeu o básico. Ele permite editar, reordenar, juntar (squash), deletar e até editar a mensagem de commits antigos como se o tempo não tivesse passado.

Instrução clara: No seu repositório de estudos, crie uma branch experimento com 5 commits desorganizados (ex.: "wip", "fix typo", "add feature x", "oops", "final"). Execute git rebase -i HEAD~5. No editor, troque pick por squash nos commits que devem ser um só, ou reword para renomear. Salve e feche. O histórico agora mostra apenas 2 commits limpos.

Erro comum a evitar: Fazer rebase em branches compartilhadas com outras pessoas. Rebase reescreve o hash dos commits, se alguém já fez checkout da branch, o histórico deles vai divergir. Regra: rebase só no que é seu ou antes de subir para o remoto.

Passo 2: Semana 1, Cherry-pick: o bisturi dos commits

Cherry-pick aplica um commit específico de qualquer branch no seu HEAD atual. Útil quando você precisa de uma correção que está em uma branch de feature, mas não quer trazer todo o histórico dela.

Instrução clara: Crie uma branch hotfix com um commit corrigindo um bug. Volte para main e execute git cherry-pick <hash-do-commit>. O commit aparece no topo de main com novo hash, mas mesma mensagem e diff. Para cherry-pick múltiplos commits, use git cherry-pick A..B (do A ao B, exclusive A).

Erro comum a evitar: Cherry-pick não mantém a relação de parentesco original. Se o commit dependia de commits anteriores que não foram aplicados, pode gerar conflito. Sempre verifique se as dependências estão satisfeitas.

Passo 3: Semana 2, Navegação e manipulação do grafo

Git stash, reflog e reset são os três mosqueteiros da navegação temporal. Stash guarda trabalho sujo temporário. Reflog é o diário de bordo do Git, tudo que você fez está lá, mesmo após um reset. Reset move o HEAD com três modos: --soft (mantém working directory e staging), --mixed (padrão, mantém working directory) e --hard (descarta tudo).

Instrução clara: Simule um desastre: faça commit, depois git reset --hard HEAD~1. O commit sumiu? Execute git reflog, ache o hash do commit perdido e faça git cherry-pick <hash> para recuperá-lo. Stash intermediário: git stash push -m "wip antes do experimento" e depois git stash pop.

Erro comum a evitar: git reset --hard sem verificar se há mudanças não commitadas. Use git status antes. Se houver, faça stash ou commit primeiro.

Passo 4: Semana 2, Git bisect: caça ao bug binária

Quando um bug aparece e você não sabe em qual commit foi introduzido, git bisect faz busca binária no histórico. Em vez de testar 100 commits um por um, ele reduz a 7 passos (log2 de 100).

Instrução clara: Identifique um commit bom (sabidamente sem o bug) e um ruim (com o bug). Inicie: git bisect start, depois git bisect good <hash-bom> e git bisect bad <hash-ruim>. O Git faz checkout de um commit no meio do intervalo. Teste: se o bug está presente, execute git bisect bad; se não, git bisect good. Repita até ele apontar o commit culpado. Finalize com git bisect reset.

Erro comum a evitar: Não automatizar o teste. Se você tem um script que retorna 0 para sucesso e !=0 para falha, use git bisect run <script>, o Git roda sozinho.

Passo 5: Semana 3, Submodules e subtrees

Submodules permitem incluir um repositório dentro de outro como referência. Útil para bibliotecas que você não quer copiar, mas precisa versionar junto. Subtrees são uma alternativa que incorpora o código sem referência externa.

Instrução clara: Adicione um submodule: git submodule add https://github.com/exemplo/lib.git libs/minha-lib. Isso cria um arquivo .gitmodules e clona o repositório. Para clonar um projeto com submodules: git clone --recurse-submodules <url>. Para atualizar: git submodule update --remote.

Erro comum a evitar: Esquecer de inicializar submodules após um clone normal. Sem --recurse-submodules, a pasta fica vazia. Execute git submodule init && git submodule update.

Passo 6: Semana 3, Hooks e automação

Git hooks são scripts que disparam em eventos como commit, push ou merge. Eles ficam na pasta .git/hooks/ e podem validar código, rodar testes, ou enviar notificações.

Instrução clara: Crie um hook pre-commit que impede commits com código mal formatado. No arquivo .git/hooks/pre-commit (sem extensão), escreva: #!/bin/sh if ! npm run lint; then echo "Lint falhou. Commit abortado." exit 1 fi Dê permissão de execução: chmod +x .git/hooks/pre-commit. Agora, se o lint falhar, o commit é bloqueado.

Erro comum a evitar: Hooks não são versionados por padrão (estão em .git/). Para compartilhá-los com a equipe, mantenha uma pasta hooks/ no repositório e um script de setup que copie para .git/hooks/.

Passo 7: Semana 4, Workflows: Git Flow, GitHub Flow e trunk-based

Git Flow é rígido: main, develop, feature/, release/, hotfix/. GitHub Flow é mais simples: main sempre deployável, branches de feature curtas com PR. Trunk-based development prega commits direto na main (ou em branches de curta duração) com feature flags.

Instrução clara: Para um projeto solo ou pequena equipe, GitHub Flow é o mais prático. Crie uma branch feature/login, faça commits, abra um PR (mesmo que virtual), faça merge para main. Para projetos com releases programadas, Git Flow organiza melhor: develop recebe features, release/1.0 congela para testes.

Erro comum a evitar: Misturar workflows. Se a equipe usa Git Flow, não faça merge direto na main. Se usa trunk-based, não crie branches que duram semanas. Alinhe o fluxo com o time.

Checklist do que você aprendeu

• [ ] Rebase interativo para limpar histórico
• [ ] Cherry-pick para aplicar commits específicos
• [ ] Stash, reflog e reset para navegação segura
• [ ] Git bisect para encontrar bugs
• [ ] Submodules para dependências externas
• [ ] Hooks para automação de qualidade
• [ ] Identificar qual workflow se aplica ao seu projeto

Perguntas frequentes sobre Git avançado

Qual a diferença entre rebase e merge?

Rebase reescreve o histórico linearizando os commits, enquanto merge cria um commit de fusão que preserva o grafo original. Rebase deixa o histórico mais limpo, mas altera hashes. Merge é mais seguro para branches compartilhadas.

Como desfazer um rebase interativo que deu errado?

Use git reflog para encontrar o estado anterior ao rebase. Execute git reset --hard <hash-do-ponto-anterior>. O reflog registra cada movimento do HEAD, inclusive rebases.

Quando usar cherry-pick em vez de merge?

Cherry-pick é ideal quando você precisa de um commit específico sem trazer todo o histórico de uma branch. Merge é melhor quando você quer integrar uma branch inteira de forma rastreável.

Git bisect funciona em repositórios grandes?

Sim, mas o tempo depende do número de commits e do custo do teste. Para repositórios com milhares de commits, a busca binária reduz o número de testes de N para log2(N). Automatizar com git bisect run acelera.

Submodules ou subtrees: qual escolher?

Submodules são mais leves (referência externa) e fáceis de atualizar, mas exigem que todos saibam usá-los. Subtrees incorporam o código, eliminando dependência externa, mas tornam atualizações mais pesadas. Escolha submodules para bibliotecas que você atualiza com frequência; subtrees para código que raramente muda.

Preciso saber tudo isso para trabalhar em equipe?

Depende do time. Rebase interativo e cherry-pick são úteis em revisões de código. Bisect é essencial em manutenção de sistemas legados. Hooks e workflows são decisões de equipe. Comece pelo que você mais usa no dia a dia e expanda.