Padrões de Fluxo de Trabalho do Git

Melhores práticas para controle de versão do Git, estratégias de ramificação e desenvolvimento colaborativo.

Quando Ativar

• Configurando o fluxo de trabalho do Git para um novo projeto
• Decidindo sobre a estratégia de ramificação (GitFlow, baseado em trunk, fluxo do GitHub)
• Escrevendo mensagens de commit e descrições de PR
• Resolvendo conflitos de merge
• Gerenciando releases e tags de versão
• Integrando novos membros da equipe às práticas do Git

Estratégias de Ramificação

Fluxo do GitHub (Simples, Recomendado para a Maioria)

Melhor para implantação contínua e equipes de pequeno a médio porte.

main (protected, always deployable)
  │
  ├── feature/user-auth      → PR → merge to main
  ├── feature/payment-flow   → PR → merge to main
  └── fix/login-bug          → PR → merge to main

Regras:

• main está sempre pronto para implantação
• Crie branches de funcionalidade a partir de main
• Abra um Pull Request quando estiver pronto para revisão
• Após aprovação e passagem do CI, faça o merge para main
• Implante imediatamente após o merge

Desenvolvimento Baseado em Trunk (Equipes de Alta Velocidade)

Melhor para equipes com CI/CD forte e flags de funcionalidade.

main (trunk)
  │
  ├── short-lived feature (1-2 days max)
  ├── short-lived feature
  └── short-lived feature

Regras:

• Todos fazem commit no main ou em branches de vida muito curta
• Flags de funcionalidade ocultam trabalho incompleto
• O CI deve passar antes do merge
• Implante várias vezes por dia

GitFlow (Complexo, Orientado por Ciclo de Lançamento)

Melhor para lançamentos agendados e projetos corporativos.

main (production releases)
  │
  └── develop (integration branch)
        │
        ├── feature/user-auth
        ├── feature/payment
        │
        ├── release/1.0.0    → merge to main and develop
        │
        └── hotfix/critical  → merge to main and develop

Regras:

• main contém apenas código pronto para produção
• develop é o branch de integração
• Branches de funcionalidade a partir de develop, faça o merge de volta para develop
• Branches de release a partir de develop, faça o merge para main e develop
• Branches de hotfix a partir de main, faça o merge para main e develop

Quando Usar Qual

Mensagens de Commit

Formato de Commits Convencionais

<type>(<scope>): <subject>

[optional body]

[optional footer(s)]

Tipos

Bons vs Maus Exemplos

# BAD: Vague, no context
git commit -m "fixed stuff"
git commit -m "updates"
git commit -m "WIP"

# GOOD: Clear, specific, explains why
git commit -m "fix(api): retry requests on 503 Service Unavailable

The external API occasionally returns 503 errors during peak hours.
Added exponential backoff retry logic with max 3 attempts.

Closes #123"

Modelo de Mensagem de Commit

Crie .gitmessage na raiz do repositório:

# <type>(<scope>): <subject>
# # Types: feat, fix, docs, style, refactor, test, chore, perf, ci, revert
# Scope: api, ui, db, auth, etc.
# Subject: imperative mood, no period, max 50 chars
#
# [optional body] - explain why, not what
# [optional footer] - Breaking changes, closes #issue

Habilite com: git config commit.template .gitmessage

Merge vs Rebase

Merge (Preserva o Histórico)

# Creates a merge commit
git checkout main
git merge feature/user-auth

# Result:
# *   merge commit
# |\
# | * feature commits
# |/
# * main commits

Use quando:

• Fazer merge de branches de funcionalidade no main
• Você quer preservar o histórico exato
• Várias pessoas trabalharam no branch

…