<h2>Fundamentos: O que é Git e Por Que Importa</h2>
<p>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.</p>
<p>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.</p>
<h3>Configuração Inicial Obrigatória</h3>
<pre><code class="language-bash">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</code></pre>
<p>Antes de trabalhar em qualquer projeto, configure sua identidade globalmente. Isso garante que seus commits sejam identificáveis e auditáveis em ambientes empresariais.</p>
<h2>Workflow Profissional: Commits, Branches e Pull Requests</h2>
<h3>Anatomia de um Bom Commit</h3>
<p>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.</p>
<pre><code class="language-bash"># 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"</code></pre>
<p>Mensagens com corpo (após linha vazia) são essenciais. Elas explicam <em>por quê</em> a mudança foi feita, não apenas <em>o quê</em>. Use o padrão Conventional Commits em projetos profissionais: <code>feat:</code>, <code>fix:</code>, <code>docs:</code>, <code>style:</code>, <code>refactor:</code>, <code>test:</code>, <code>chore:</code>.</p>
<h3>Branches: Estratégia Git Flow</h3>
<p>Em projetos reais, nunca trabalhe diretamente em <code>main</code> ou <code>master</code>. Use branching strategy como Git Flow, onde cada feature, bugfix ou release tem sua própria branch.</p>
<pre><code class="language-bash"># 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</code></pre>
<p>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.</p>
<h2>Cenários Reais: Resolvendo Problemas</h2>
<h3>Reverter Alterações Sem Perder Histórico</h3>
<p>Em produção, <code>git revert</code> é seu melhor amigo. Ele cria um novo commit que desfaz mudanças, mantendo rastreabilidade completa.</p>
<pre><code class="language-bash"># 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!</code></pre>
<h3>Integrar Mudanças de Outro Desenvolvedor</h3>
<pre><code class="language-bash"># 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</code></pre>
<p>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.</p>
<h3>Encontrar Bugs com Git Bisect</h3>
<p>Quando você sabe que um bug existe na produção mas não sabe em qual commit:</p>
<pre><code class="language-bash">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</code></pre>
<h2>Boas Práticas para Equipes</h2>
<p>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.</p>
<p>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.</p>
<h2>Conclusão</h2>
<p>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: <strong>(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á.</strong></p>
<p>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.</p>
<h2>Referências</h2>
<ul>
<li><a href="https://git-scm.com/doc" target="_blank" rel="noopener noreferrer">Git Official Documentation</a></li>
<li><a href="https://www.conventionalcommits.org/" target="_blank" rel="noopener noreferrer">Conventional Commits</a></li>
<li><a href="https://www.atlassian.com/git/tutorials/advanced-overview" target="_blank" rel="noopener noreferrer">Atlassian Git Tutorials - Advanced</a></li>
<li><a href="https://git-scm.com/book/en/v2" target="_blank" rel="noopener noreferrer">Pro Git Book - Free Online</a></li>
<li><a href="https://chris.beams.io/posts/git-commit/" target="_blank" rel="noopener noreferrer">GitHub - How to write good commit messages</a></li>
</ul>