Trabalho em equipe: PRs, review e convenções — Git e trabalho em equipe

Fluxos de trabalho

Um fluxo (workflow) são as regras de como a equipe leva mudanças para produção. Dois modernos e simples:

GitHub flow: main sempre pronta para deploy. Para cada mudança você cria uma branch curta, abre um Pull Request, ele é revisado, é feito o merge e o deploy.
Trunk-based development: todos integram muito frequentemente (várias vezes ao dia) em uma única branch principal (main/trunk) com branches de vida muito curta. Evita branches longevas que divergem e provocam merges dolorosos.

Ambos compartilham a mesma ideia: branches pequenas e de vida curta, e integração frequente.

git switch -c feature/carrinho
# ... commits ...
git push -u origin feature/carrinho   # envia a branch para o remoto

Pull Request (PR)

Um Pull Request (ou Merge Request) é uma solicitação para fazer merge da sua branch em outra (normalmente main). Não é um comando do Git: é um recurso da plataforma (GitHub/GitLab) que adiciona, sobre o merge, um espaço de revisão:

mostra o diff completo das mudanças,
permite comentários linha a linha e discussão,
executa a CI (testes, lint, build) automaticamente,
registra aprovações antes de você poder fazer o merge.

O code review é a revisão por outra pessoa: detecta erros, compartilha conhecimento e mantém a qualidade. Você pede aprovação, atende aos comentários e só então é feito o merge.

Conventional Commits

Conventional Commits é uma convenção para as mensagens de commit com um formato fixo, legível por máquinas e humanos:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé opcional, p. ex. BREAKING CHANGE: ...]

Tipos comuns:

git commit -m "feat: adiciona filtro por categoria"   # nova funcionalidade
git commit -m "fix: corrige o cálculo do total"   # correção de bug
git commit -m "docs: atualiza o README"
git commit -m "refactor: extrai o serviço de pagamentos"
git commit -m "test: cobre o carrinho vazio"
git commit -m "chore: atualiza dependências"

Uma mudança incompatível (quebra a API pública) é marcada com ! ou com um rodapé BREAKING CHANGE::

git commit -m "feat!: muda a assinatura de createUser"

Vantagem: permite gerar o changelog e decidir o salto de versão (semver) de forma automática a partir das mensagens.

Proteção de branches e CODEOWNERS

Em equipes, main é protegida para que ninguém possa quebrá-la. Regras típicas:

proibir push direto: tudo entra por PR;
exigir N aprovações antes do merge;
exigir que a CI passe (testes/lint no verde);
proibir force-push e exclusão da branch.

O arquivo CODEOWNERS define quem é responsável (revisor obrigatório) por cada parte do código. Ao mexer nesses arquivos, o dono deles é adicionado automaticamente como revisor do PR:

# .github/CODEOWNERS
*.ts            @time-frontend
/infra/         @time-devops
/src/pagamentos/  @ana @luis