Noções Básicas de Git para Equipes Node

# Trabalho diário de features
git checkout main && git pull --ff-only
git checkout -b feat/API-412-add-refund-endpoint
# ... commits com mensagens convencionais ...
git push -u origin feat/API-412-add-refund-endpoint
# Abrir PR → squash merge para main após CI verde

# Corte de release (quando API + workers são enviados juntos)
git checkout main && git pull --ff-only
git checkout -b release/2.6.0
git push -u origin release/2.6.0
# Apenas correções de bugs até a tag; migrações coordenadas nas notas de release

# Tag após aprovação do staging
git checkout release/2.6.0
git tag -a v2.6.0 -m "Release 2.6.0 - orders-api + email-worker"
git push origin v2.6.0

Filas de branches (backends Node)
  main              ← integração; CI sempre verde
  feat/*            ← dias; squash merge
  release/X.Y       ← semanas; trem de deploy coordenado
  hotfix/X.Y.Z      ← horas; a partir da tag vX.Y.(Z-1)

# Nunca ignore lockfiles
git check-ignore package-lock.json && echo "RUIM" || echo "OK"
 
# .gitignore deve excluir
# node_modules/
# dist/
# .env
# coverage/

// package.json
{
  "engines": { "node": "24.18.0" }
}

git commit -m "feat(orders): add refund endpoint [API-412]"
git commit -m "fix(worker): retry webhook on 429 [API-415]"
git commit -m "chore(deps): bump fastify to 5.x [API-420]"

## Checklist da Release 2.6.0
- [ ] migração orders-api 20260709_refunds.sql mesclada para release/2.6.0
- [ ] email-worker compatível com o novo schema de eventos
- [ ] Ordem de deploy: migração → worker → API (documentar no runbook)
- [ ] Tag v2.6.0 dispara o workflow de release do GitHub Actions

git checkout -b hotfix/2.5.1 v2.5.0
# corrige apenas bug de produção
git tag -a v2.5.1 -m "Hotfix: pool leak in webhook handler"
git push origin v2.5.1
# Cherry-pick do SHA do fix para main E abrir release/2.6.0 se ainda estiver ativa