Boas Práticas de Git
Um resumo condensado das 25 práticas Git mais importantes para trabalho com banco de dados PostgreSQL 18.4 - conteúdo portátil compartilhado; personalize de acordo com as convenções da organização.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 práticas Git mais importantes para trabalho com banco de dados PostgreSQL 18.4 - conteúdo portátil compartilhado; personalize de acordo com as convenções da organização.
main é a verdade da integração: Cada migração mesclada passa por flyway validate em staging; nunca deixe SQL quebrado na ponta (Noções Básicas de Git para Trabalho com Banco de Dados).
IDs de Ticket nos nomes de arquivo de migração e commits: V20260709_128__orders_priority.sql e feat(db): ... [DB-128].
Nunca edite o conteúdo de migrações aplicadas: Novos arquivos forward corrigem erros; desvios de checksum quebram deploys.
Proteja main com CI de migração: Verificação obrigatória de flyway migrate + flyway validate.
Squash de branches de feature antes do merge: Um ticket, uma série lógica de migrações em main.
Branches de curta duração: Alvo de 1-3 dias; rebase de main diariamente para evitar colisões de números de versão.
Branch de release para coordenação de schema + trem de aplicativos: Migrações mescladas para release/* antes da tag.
Cherry-pick de migrações para release/*, nunca mescle main cegamente: Evite puxar schema não verificado para o candidato a release.
Tag após migração em staging + aprovação do aplicativo: A mensagem da tag lista as versões de migração aplicadas.
Mescle release/* de volta para main após o rollout: Preserve o limite do trem.
Branches de hotfix de migração a partir da tag de produção: O hotfix de schema corresponde ao ponto de partida da produção.
Backport do SHA do hotfix de migração para main: No mesmo dia; desvios criam estados impossíveis para o flyway.
Nunca force push em main ou release/*: O histórico é evidência de auditoria para revisões SOX e SOC.
O template de PR exige SQL de rollback: Mesmo a política de produção apenas forward armazena scripts de descida em db/rollback/.
O template de PR exige label de risco de bloqueio: baixo / médio / alto da Habilidade de Segurança de Migração.
Evidência EXPLAIN para mudanças de query: Anexada no PR ou artefato de CI linkado.
Sem DDL psql em produção sem commit git em 24h: Script de emergência mesclado via branch de hotfix.
Não comite arquivos de dados pg_dump: Apenas schema SQL; dados via pipeline seguro separado.
Arquivos .sql em UTF-8 sem BOM: Evite surpresas de checksum do flyway em editores Windows.
Monorepo: uma sequência de migração por banco de dados: Documente se múltiplos bancos de dados usam pastas separadas.
Migrações repetíveis (R__) para views/funções: Migrações versionadas apenas para DDL de uso único.
Lockfile para ferramentas: Fixe a tag da imagem Docker do flyway em CI, não latest.
Proteção de branch exige revisão de DBA em db/migrations/**: Aplicado pelo arquivo CODEOWNERS.
Documente a ordem de deploy nas notas de release: padrão migração → worker → API.
Query de verificação pós-deploy no runbook: SELECT version FROM flyway_schema_history corresponde às notas da tag.
Prefira trunk (main) + release/* de curta duração + hotfix/*. Um develop de longa duração desvia as versões de migração do histórico flyway de produção.
main + branches de feature + CI flyway em staging + nunca edite migrações mescladas. Adicione branches de release quando o QA de staging entrar.
PR dispara migração em staging; tag dispara job de migração em produção antes do deploy do aplicativo. Veja Flyway e Liquibase.
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4, Flyway 10+ e fluxos de PR GitHub / GitLab.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026