7 min leitura • Guide 327 of 877
Configurando Regras de Proteção de Branch
Regras de proteção de branch são seus guardiões automatizados. Elas garantem que revisões de código aconteçam, testes passem e branches críticos permaneçam estáveis. Proteção configurada adequadamente previne erros custosos e impõe padrões da equipe sem policiamento manual.
Opções de Proteção
| Proteção | Propósito | Recomendado |
|---|---|---|
| Exigir PR | Sem push direto | ✓ Sempre |
| Exigir revisão | Qualidade de código | ✓ Sempre |
| Exigir CI | Testes passam | ✓ Sempre |
| Atualizada | Sem conflitos de merge | ✓ Geralmente |
| Bloquear force push | Preservar histórico | ✓ Sempre |
Configuração do GitHub
Configurando Proteção
PROTEÇÃO DE BRANCH DO GITHUB
════════════════════════════
ACESSO:
─────────────────────────────────────
Settings → Branches → Add rule
├── Branch name pattern: main
└── Configure protections
PROTEÇÕES OBRIGATÓRIAS:
─────────────────────────────────────
☑ Require a pull request before merging
├── Required approvals: 1 (equipe pequena) ou 2 (maior)
├── Dismiss stale pull request approvals
│ └── Mudanças após aprovação precisam re-revisão
├── Require review from Code Owners
│ └── Usar arquivo CODEOWNERS
└── Require approval of most recent push
└── Previna commits furtivos após aprovação
☑ Require status checks to pass
├── Require branches to be up to date
├── Add checks:
│ ├── ci/build
│ ├── ci/test
│ ├── ci/lint
│ └── security/scan
└── Todos devem passar antes do merge
☑ Require conversation resolution
└── Todos comentários do PR devem ser resolvidos
☑ Require signed commits (opcional)
└── Para repositórios de alta segurança
RESTRIÇÕES DE PUSH:
─────────────────────────────────────
☑ Restrict who can push to matching branches
├── Selecionar equipes/usuários permitidos
├── Apenas para emergências
└── Geralmente: ninguém (todos via PR)
☑ Do not allow bypassing the above settings
└── Mesmo admins devem seguir regras
☑ Block force pushes
└── Proteger histórico
☑ Block deletions
└── Não pode deletar branches protegidas
Rulesets do GitHub
RULESETS DO GITHUB (MAIS NOVO)
══════════════════════════════
VANTAGENS SOBRE REGRAS DE BRANCH:
─────────────────────────────────────
├── Aplicar no nível da organização
├── Alvo múltiplas branches/repos
├── Permissões de bypass mais granulares
├── Regras de tag incluídas
├── Melhor trilha de auditoria
└── Recomendado para empresa
CRIANDO UM RULESET:
─────────────────────────────────────
Repository → Settings → Rules → Rulesets
Novo ruleset:
├── Name: "Production Protection"
├── Enforcement: Active
├── Target branches: main, release/*
└── Configure rules
OPÇÕES DE RULESET:
─────────────────────────────────────
Regras de branch:
├── Restrict creations
├── Restrict updates
├── Restrict deletions
├── Require linear history
├── Require deployments to succeed
├── Require signed commits
├── Require a pull request
├── Require status checks
└── Block force pushes
Lista de bypass:
├── Repository admins
├── Equipes específicas (ex.: Release Team)
├── Deploy keys
└── Acesso de emergência definido
Configuração do GitLab
Branches Protegidas
BRANCHES PROTEGIDAS DO GITLAB
═════════════════════════════
ACESSO:
─────────────────────────────────────
Settings → Repository → Protected branches
CONFIGURAÇÃO:
─────────────────────────────────────
Branch: main
Allowed to merge:
├── Maintainers (comum)
├── Developers + Maintainers
├── No one (via MR only)
└── Controle baseado em role
Allowed to push:
├── No one (recomendado)
├── Forçar workflow CI/MR
└── Todas mudanças via MR
Allowed to force push:
├── No (sempre)
└── Protege histórico
Code owner approval:
├── Required from CODEOWNERS
└── Expertise de domínio imposta
CONFIGURAÇÕES DE MERGE REQUEST:
─────────────────────────────────────
Settings → Merge Requests
☑ Pipelines must succeed
☑ All threads must be resolved
☑ Skipped pipelines considered successful: No
☑ Merge method: Merge commit / Squash / Rebase
└── Preferência da equipe
Verificações de Status
Exigindo que CI Passe
CONFIGURAÇÃO DE VERIFICAÇÃO DE STATUS
═════════════════════════════════════
QUAIS VERIFICAÇÕES EXIGIR:
─────────────────────────────────────
Essenciais:
├── Build: Deve compilar/build
├── Test: Testes unitários passam
├── Lint: Padrões de código atendidos
└── Portões não-negociáveis
Recomendadas:
├── Scan de segurança
├── Verificação de tipos
├── Testes de integração
├── Threshold de cobertura
└── Barra de qualidade mais alta
Opcionais:
├── Testes de performance
├── Deploy de preview
├── Verificação de documentação
└── Nice-to-have
CONFIGURANDO VERIFICAÇÕES:
─────────────────────────────────────
1. Criar workflow que reporta status:
name: CI
on: pull_request
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run build
- run: npm test
2. Adicionar às verificações obrigatórias:
Settings → Branches → Edit rule
→ Add "build" to required checks
LIDANDO COM TESTES INSTÁVEIS:
─────────────────────────────────────
Opções:
├── Corrigir o teste instável (melhor)
├── Lógica de retry no CI
├── Remover do obrigatório (temporário)
└── Não deixar instável bloquear equipe
Bypass de Emergência
Lidando com Correções Urgentes
PROCEDIMENTOS DE EMERGÊNCIA
═══════════════════════════
OPÇÕES DE BYPASS:
─────────────────────────────────────
Opção 1: Lista de bypass
├── Pessoas específicas podem bypass
├── Engenheiros seniores / leads
├── Uso apenas de emergência
├── Auditado no histórico git
└── Definir em ruleset
Opção 2: Regras de branch hotfix
├── hotfix/* tem proteção mais leve
├── Talvez 1 revisor vs 2
├── Mesmos requisitos CI
├── Caminho mais rápido para urgente
└── Regra de proteção separada
Opção 3: Desabilitar temporário
├── Admin desabilita regra
├── Push correção
├── Re-habilitar imediatamente
├── Documentar no log de incidente
├── Último recurso
└── Tem trilha de auditoria
PROCESSO DE EMERGÊNCIA:
─────────────────────────────────────
1. Criar branch hotfix/*
2. Fazer correção mínima
3. Revisão rápida (1 pessoa)
4. CI deve passar (abreviado)
5. Merge para main
6. Cherry-pick para release se necessário
7. Revisão completa pós-mortem
8. Log no registro de incidente
EQUILÍBRIO:
─────────────────────────────────────
├── Proteção é importante
├── Emergências acontecem
├── Definir processo antecipadamente
├── Não tornar bypasses comuns
├── Revisar após cada bypass
└── Melhoria contínua
Proprietários de Código
Revisão Baseada em Domínio
ARQUIVO CODEOWNERS
══════════════════
PROPÓSITO:
─────────────────────────────────────
├── Atribuição automática de revisão
├── Garantir que experts certos revisem
├── Propriedade de áreas de código
├── Aprovação obrigatória para mudanças
└── Imposição de expertise de domínio
LOCALIZAÇÃO DO ARQUIVO:
─────────────────────────────────────
.github/CODEOWNERS
# ou
docs/CODEOWNERS
# ou
CODEOWNERS (root)
SINTAXE:
─────────────────────────────────────
# Proprietários padrão para tudo
* @team-lead @senior-dev
# Propriedade frontend
/src/components/ @frontend-team
*.tsx @frontend-team
*.css @frontend-team
# Propriedade backend
/src/api/ @backend-team
/src/services/ @backend-team
# Infraestrutura
/terraform/ @platform-team
/docker/ @platform-team
*.yml @devops-team
# Sensível à segurança
/src/auth/ @security-team @team-lead
/src/payments/ @security-team @backend-team
RESULTADO:
─────────────────────────────────────
├── PR tocando /src/auth/ → security-team auto-adicionado
├── Deve aprovar para merge
├── Experts de domínio envolvidos
├── Nenhuma mudança escapa
└── Atribuição automática
Integração com GitScrum
Visibilidade de Proteção
GITSCRUM COM PROTEÇÃO DE BRANCH
═══════════════════════════════
VISIBILIDADE DE STATUS DO PR:
─────────────────────────────────────
Na tarefa:
├── Status do PR mostrado
├── Checks passando/falhando
├── Status de revisão
├── Prontidão para merge
└── Saúde de relance
CONSCIÊNCIA DE WORKFLOW:
─────────────────────────────────────
├── Tarefa move "Em Revisão" → PR aberto
├── Tarefa vê status de checks do PR
├── Bloqueada se checks falham
├── Desbloqueada quando pronta para merge
└── Status da tarefa reflete realidade
Melhores Práticas
Para Proteção de Branch
- Proteja main sempre — Não-negociável
- Exija revisões — Portão de qualidade de código
- Exija CI — Verificação automatizada
- Use Code Owners — Experts certos revisam
- Planeje caminho de emergência — Mas use raramente
Anti-Padrões
ERROS DE PROTEÇÃO DE BRANCH:
✗ Nenhuma proteção no main
✗ Admins bypassam rotineiramente
✗ Checks CI opcionais
✗ Nenhuma revisão obrigatória
✗ Bypass muito frequente
✗ Force push permitido
✗ Sem CODEOWNERS para código crítico
✗ Processo de emergência indefinido