APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma aprovação deve corresponder ao diff que vai ser integrado. Se chegam commits depois da revisão, configura a política adequada para repor aprovações ou exigir revisão da última iteração. No Azure Repos, filtros de caminhos também delimitam o controlo: uma regra para /app não cobre necessariamente /infra. Inclui IaC e definições de pipeline na revisão por pessoas com competência para avaliar o impacto. Confirma permissões de bypass: completar um PR ignorando policies e fazer push direto são permissões distintas. A existência de uma policy falhada na UI não prova que bloqueou uma identidade autorizada a contorná-la. Usa exceções delimitadas e auditáveis.
Aplicação guiada
Para reverter um commit normal já partilhado sem reescrever histórico, git revert cria uma nova alteração inversa. Revê e testa essa alteração; não suponhas que elimina efeitos já produzidos fora do repositório. Se foi publicado um segredo válido, a prioridade é revogar ou rodar a credencial e avaliar exposição. Apagar o ficheiro atual não remove todas as cópias nem invalida o token. Uma limpeza de histórico exige coordenação e não substitui revogação. Para ficheiros binários grandes, Git LFS conserva ponteiros no Git e objetos separados; o pipeline precisa de acesso a ambos. No fecho de um hotfix de emergência, regista o diff final, evidência de validação e retirada do acesso temporário.
O PR aprovado recebeu uma alteração de autorização. A aprovação do diff anterior não é evidência de revisão do novo.
Armadilhas comuns
Aprovação antiga como permanente; bypass esquecido; apagar segredo como revogação; ponteiro LFS como binário.
Tópicos relacionados: Artefactos, dependências e agentes · YAML, condições e aprovações
Liga cada aprovação à revisão final e cada exceção ao seu encerramento.
Referência: Branch policies · AZ-400 objectives 2026-07-27