Mejores Prácticas de Git
Un resumen condensado de las 25 prácticas más importantes de Git para el trabajo de base de datos PostgreSQL 18.4 - contenido portátil compartido; personaliza según las convenciones de la organización.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 prácticas más importantes de Git para el trabajo de base de datos PostgreSQL 18.4 - contenido portátil compartido; personaliza según las convenciones de la organización.
main es la verdad de la integración: Cada migración fusionada pasa flyway validate en staging; nunca dejes SQL roto en la punta (Fundamentos de Git para Trabajo de Base de Datos).
IDs de Ticket en nombres de archivo de migración y commits: V20260709_128__orders_priority.sql y feat(db): ... [DB-128].
Nunca edites el contenido de migraciones aplicadas: Un nuevo archivo forward corrige errores; la deriva de checksum rompe los despliegues.
Protege main con CI de migración: Se requiere flyway migrate + flyway validate.
Squash de ramas de funcionalidad antes de fusionar: Un ticket, una serie lógica de migraciones en main.
Ramas de corta duración: Objetivo de 1-3 días; haz rebase de main diariamente para evitar colisiones de números de versión.
Rama de release para sincronización coordinada de esquema + aplicación: Las migraciones se fusionan a release/* antes de etiquetar.
Cherry-pick de migraciones a release/*, nunca fusiones main ciegamente: Evita incorporar esquemas no verificados al candidato de release.
Etiqueta después de la aprobación de migración + aplicación en staging: El mensaje de la etiqueta lista las versiones de migración aplicadas.
Fusiona release/* de vuelta a main después del despliegue: Conserva el límite del tren.
Ramas de hotfix de migración desde la etiqueta de producción: El hotfix del esquema coincide con el punto de partida de producción.
Backport del SHA del hotfix de migración a main: Mismo día; la deriva crea estados imposibles de flyway.
Nunca hagas force-push a main o release/*: El historial es evidencia de auditoría para revisiones SOX y SOC.
La plantilla de PR requiere SQL de rollback: Incluso la política de producción solo hacia adelante almacena scripts de bajada en db/rollback/.
La plantilla de PR requiere etiqueta de riesgo de bloqueo: bajo / medio / alto de la Habilidad de Seguridad de Migración.
Evidencia EXPLAIN para cambios de consulta: Adjunta en PR o enlace a artefacto CI.
No DDL psql en producción sin commit git dentro de las 24h: Script de emergencia fusionado a través de rama de hotfix.
No cometas archivos de datos pg_dump: Solo SQL de esquema; datos a través de un pipeline seguro separado.
Archivos .sql en UTF-8 sin BOM: Evita sorpresas de checksum de flyway en editores de Windows.
Monorepo: una secuencia de migración por base de datos: Documenta si múltiples bases de datos usan carpetas separadas.
Migraciones repetibles (R__) para vistas/funciones: Migraciones versionadas solo para DDL de una sola vez.
Lockfile para herramientas: Fija la etiqueta de la imagen Docker de flyway en CI, no latest.
La protección de ramas requiere revisión de DBA en db/migrations/**: Forzado por el archivo CODEOWNERS.
Documenta el orden de despliegue en las notas de release: Patrón estándar de migración → worker → API.
Consulta de verificación post-despliegue en el runbook: SELECT version FROM flyway_schema_history coincide con las notas de la etiqueta.
Prefiere trunk (main) + release/* de corta duración + hotfix/*. Un develop de larga duración deriva las versiones de migración del historial de flyway de producción.
main + ramas de funcionalidad + CI de flyway en staging + nunca editar migraciones fusionadas. Agrega ramas de release cuando se una QA de staging.
El PR activa la migración de staging; la etiqueta activa el trabajo de migración de producción antes del despliegue de la aplicación. Ver Flyway y Liquibase.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4, Flyway 10+, y flujos de trabajo de PR de GitHub / GitLab.
Revisado por Chris St. John·Última actualización: 16 jul 2026