Git Pie: A Arte Ancestral do Versionamento 🥧 Help

Melhores Práticas em Controle de Versão

O controle de versão é fundamental para o desenvolvimento de software moderno. Aqui estão as práticas essenciais para manter seu código organizado e sua equipe produtiva.

Por que Seguir Boas Práticas?

BenefíciosQualidadeProdutividadeSegurançaCódigo LimpoRastreabilidadeMenos ConflitosColaboração EficienteBackupAuditoria

Princípios Fundamentais

1. Consistência

  • Mantenha padrões de código

  • Siga convenções de commit

  • Use nomenclatura uniforme

2. Atomicidade

  • Commits pequenos e focados

  • Uma feature por branch

  • Mudanças relacionadas juntas

3. Rastreabilidade

  • Commits descritivos

  • Referência a issues

  • Documentação atualizada

Organização de Repositório

Estrutura de Diretórios

projeto/ ├── src/ ├── tests/ ├── docs/ ├── .gitignore └── README.md

Arquivos Essenciais

  • README.md

  • .gitignore

  • CONTRIBUTING.md

  • LICENSE

Commits

Anatomia de um Bom Commit

CommitTítuloCorpoMetadadosCurtoDescritivoImperativoContextoMotivaçãoImpactoIssue IDBreaking ChangesCo-authors

Padrão de Mensagens

Ex: feat, fix

Ex: auth, api

Imperativo

Opcional

Tipo

Escopo

Descrição

Corpo

Footer

Convenção de Commits

<tipo>(<escopo>): <descrição> [corpo] [footer] Exemplos: ✅ feat(auth): adiciona autenticação via Google ✅ fix(api): corrige timeout em requisições longas ✅ docs(readme): atualiza instruções de instalação ✅ style(login): ajusta layout responsivo ✅ refactor(core): migra para TypeScript ✅ test(unit): adiciona testes para módulo de pagamento

Tipos de Commit

TiposFuncionalidadesCódigoDocumentaçãoInfraestruturaTestesfeatfixrefactorstyledocscommentsbuildcitestperf

Fluxo de Trabalho

ReviewGitDeveloperReviewGitDeveloperCodifica mudançasTesta localmentegit add [files]git commit -m "mensagem"Push para reviewFeedbackAjustes se necessário

Commits Atômicos

Sim

Não

Uma mudança lógica

Commit único

É atômico?

Perfect!

Dividir em
múltiplos commits

O que Evitar

❌ Commits Ruins: └── "correções" └── "wip" └── "updates" └── "fix bugs" └── "commit final" └── "alterações diversas" ✅ Commits Bons: └── "feat(user): adiciona validação de email" └── "fix(auth): corrige refresh token expirado" └── "refactor(api): simplifica tratamento de erros" └── "docs(swagger): atualiza documentação da API"

Dicas para Commits Efetivos

CommitsQuando CommitarComo CommitarPor que CommitarMudança completaTestes passandoCódigo revisadoMensagem claraMudanças relacionadasTamanho adequadoHistórico claroRastreabilidadeColaboração

Ferramentas Úteis

ToolsConventional CommitsGit HooksAutomaçãocommitlintcommitizenhuskypre-commitsemantic-releasestandard-version

Revisão de Commits

Novo Commit

Checklist

Mensagem clara?

Mudança atômica?

Testes incluídos?

Documentação atualizada?

Commit aprovado

Boas Práticas de Reescrita

🔄 Reescrita de Commits Local (antes do push): ├── git commit --amend ├── git rebase -i └── git reset Remoto (com cuidado): ├── Squash merges ├── Rebase time └── Force push (-f)

Gerenciamento de Branches

Fluxo de Desenvolvimento

maindevelopfeature/loginfeature/profile0-d5705991-d38d3a52-4934a6a3-5cb7efa5-a54ab436-3ca480f

Estrutura de Branches

main

develop

feature/*

bugfix/*

hotfix/*

release/*

Ciclo de Vida de uma Branch

ReviewFeatureDevelopMainReviewFeatureDevelopMainCriar branchDesenvolvimentoTestes locaisPull RequestCode ReviewAjustesMergeRelease

Convenções de Nomenclatura

BranchesFeatureBugfixHotfixReleasefeature/loginfeature/user-profilebugfix/login-errorbugfix/profile-crashhotfix/security-fixhotfix/critical-bugrelease/1.0.0release/2.0.0

Code Review

Checklist

  • [ ] Código segue padrões

  • [ ] Testes adicionados/atualizados

  • [ ] Documentação atualizada

  • [ ] Performance considerada

  • [ ] Segurança verificada

Feedback Construtivo

  • Foco no código, não no desenvolvedor

  • Sugestões específicas

  • Explicações claras

  • Reconhecimento de boas práticas

21 abril 2025