Fundamentos: O que é Git e Por Que Importa
Git é um sistema de controle de versão distribuído que permite rastrear mudanças no código, colaborar com outros desenvolvedores e manter um histórico completo do projeto. Diferente de sistemas centralizados, cada desenvolvedor possui uma cópia completa do repositório, oferecendo flexibilidade e segurança. Em projetos reais, Git não é opcional — é a base para qualidade, rastreabilidade e integração contínua.
A estrutura do Git funciona em três níveis: working directory (seus arquivos), staging area (preparação de commits) e repository (histórico). Entender esse fluxo é essencial antes de escrever qualquer comando. Um commit bem feito conta uma história, enquanto commits confusos criam débito técnico que afeta toda a equipe.
Configuração Inicial Obrigatória
git config --global user.name "Seu Nome"
git config --global user.email "seu.email@empresa.com"
git config --global core.editor "vim" # ou seu editor favorito
git config --list # Verifica todas as configurações
Antes de trabalhar em qualquer projeto, configure sua identidade globalmente. Isso garante que seus commits sejam identificáveis e auditáveis em ambientes empresariais.
Workflow Profissional: Commits, Branches e Pull Requests
Anatomia de um Bom Commit
Um commit é uma snapshot do projeto em um momento específico. Em projetos reais, commits devem ser atômicos (uma responsabilidade por commit) e com mensagens claras. A diferença entre um projeto caótico e um bem mantido frequentemente resume-se à qualidade das mensagens de commit.
# Fluxo correto de staging e commit
git add src/controllers/UserController.js # Stage arquivo específico
git add -p # Adiciona partes de arquivos interativamente (recomendado!)
git status # Sempre verifique antes de committar
git commit -m "feat: adiciona validação de email no registro de usuários
- Implementa regex para validação de domínio
- Adiciona testes unitários
- Atualiza documentação da API"
Mensagens com corpo (após linha vazia) são essenciais. Elas explicam por quê a mudança foi feita, não apenas o quê. Use o padrão Conventional Commits em projetos profissionais: feat:, fix:, docs:, style:, refactor:, test:, chore:.
Branches: Estratégia Git Flow
Em projetos reais, nunca trabalhe diretamente em main ou master. Use branching strategy como Git Flow, onde cada feature, bugfix ou release tem sua própria branch.
# Criar branch de feature
git checkout -b feature/autenticacao-oauth2
# ou (sintaxe mais recente)
git switch -c feature/autenticacao-oauth2
# Trabalhar normalmente
echo "código de autenticação" > auth.js
git add auth.js
git commit -m "feat: implementa fluxo OAuth2 com Google"
# Verificar diferenças antes de sincronizar
git log --oneline main..feature/autenticacao-oauth2
git diff main feature/autenticacao-oauth2
# Sincronizar com main (antes de PR)
git fetch origin
git rebase origin/main # ou merge, depende da política
Pull Requests são a porta de entrada: código review obrigatório, testes automatizados rodando, discussão técnica assincrona. Isso não é burocracia — é qualidade.
Cenários Reais: Resolvendo Problemas
Reverter Alterações Sem Perder Histórico
Em produção, git revert é seu melhor amigo. Ele cria um novo commit que desfaz mudanças, mantendo rastreabilidade completa.
# Identificar o commit problemático
git log --oneline -n 20
# Reverter apenas esse commit (mantém histórico)
git revert abc123def --no-edit
# Versus git reset (apaga história — use com cuidado!)
git reset --soft HEAD~1 # Desfaz commit, mantém alterações staged
git reset --hard HEAD~1 # ⚠️ Apaga tudo — cuidado em branches compartilhadas!
Integrar Mudanças de Outro Desenvolvedor
# Cenário: main foi atualizada por outro dev
git fetch origin
git log --oneline main..origin/main # Vê o que falta
# Opção 1: Rebase (histórico linear, recomendado em features)
git rebase origin/main
# Opção 2: Merge (cria merge commit, recomendado em main)
git merge origin/main
Rebase é preferido em branches de feature porque mantém histórico limpo. Merge é preferido ao integrar na main porque preserva contexto de quando branches foram mescladas.
Encontrar Bugs com Git Bisect
Quando você sabe que um bug existe na produção mas não sabe em qual commit:
git bisect start
git bisect bad HEAD # Commit atual está quebrado
git bisect good v1.2.0 # Última versão conhecida como boa
# Git automaticamente faz checkout em commits intermediários
# Você testa se está quebrado ou bom
git bisect bad # Se quebrado
# ou
git bisect good # Se funcionando
# Ao final, Git identifica o primeiro commit problemático
git bisect reset # Volta ao estado anterior
Boas Práticas para Equipes
Trabalhar com Git em equipes reais exige disciplina compartilhada. Estabeleça padrões claros: política de branches, quando fazer rebase vs merge, como nomear branches, e quem pode fazer merge em main. Automatize tudo possível — linting, testes, build — antes que o código chegue a revisão humana.
Mensagens de commit e historicamente bem mantido economizam semanas de debugging futuro. Quando você precisa entender por que uma linha de código existe no meio da noite em produção, um histórico claro é ouro puro.
Conclusão
Git domina projetos profissionais porque resolve dois problemas críticos: colaboração sem conflitos e rastreabilidade completa. Os três pilares que você precisa internalizar são: (1) commits atômicos com mensagens claras criam histórico que faz sentido; (2) branches e PRs são controle de qualidade, não overhead; (3) conhecer git revert, rebase e bisect resolve 95% dos problemas reais que você encontrará.
Comece pequeno — pratique esses comandos em um repositório pessoal até que sejam instintivos. Depois, implemente em equipe com paciência. Git é ferramenta; a disciplina é a habilidade.