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.

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.

FAQs

Branch develop do GitFlow para banco de dados?

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.

Mínimo para desenvolvedor solo?

main + branches de feature + CI flyway em staging + nunca edite migrações mescladas. Adicione branches de release quando o QA de staging entrar.

Como conectar Git aos runners de migração?

PR dispara migração em staging; tag dispara job de migração em produção antes do deploy do aplicativo. Veja Flyway e Liquibase.

Relacionados

Noções Básicas de Git para Trabalho com Banco de Dados - fluxo trunk
Revisão de Código para SQL - checklist de PR
Boas Práticas de Migrações - regras de alteração de schema
Habilidade de Segurança de Migração - pontuação de bloqueio

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4, Flyway 10+ e fluxos de PR GitHub / GitLab.

Boas Práticas de Git

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.

FAQs

Branch develop do GitFlow para banco de dados?

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.

Mínimo para desenvolvedor solo?

main + branches de feature + CI flyway em staging + nunca edite migrações mescladas. Adicione branches de release quando o QA de staging entrar.

Como conectar Git aos runners de migração?

PR dispara migração em staging; tag dispara job de migração em produção antes do deploy do aplicativo. Veja Flyway e Liquibase.

Boas Práticas de Git

FAQs

Relacionados

Buscar na documentação

Boas Práticas de Git

FAQs

Relacionados