¿Cómo puedo poner una base de datos bajo git (control de versiones)?
Estoy creando una aplicación web y necesito crear una rama para algunos cambios importantes. La cuestión es que estos cambios requieren cambios en el esquema de la base de datos, por lo que también me gustaría colocar toda la base de datos en git.
¿Cómo puedo hacer eso? ¿Existe una carpeta específica que pueda guardar en un repositorio de Git? ¿Cómo sé cuál? ¿Cómo puedo estar seguro de que estoy colocando la carpeta correcta?
Necesito estar seguro, porque estos cambios no son compatibles con versiones anteriores; No puedo permitirme el lujo de equivocarme.
La base de datos en mi caso es PostgreSQL
Editar:
Alguien sugirió realizar copias de seguridad y poner el archivo de copia de seguridad bajo control de versiones en lugar de la base de datos. Para ser honesto, me resulta muy difícil de aceptar.
Tiene que haber una mejor manera.
Actualizar:
Bien, no hay mejor manera, pero todavía no estoy del todo convencido, así que cambiaré un poco la pregunta:
Me gustaría poner toda la base de datos bajo control de versiones, ¿qué motor de base de datos puedo usar para poder poner la base de datos real bajo control de versiones en lugar de su volcado?
¿Sqlite sería compatible con git?
Como este es sólo el entorno de desarrollo, puedo elegir la base de datos que quiera.
Editar2:
Lo que realmente quiero no es realizar un seguimiento de mi historial de desarrollo, sino poder cambiar de mi rama de "nuevos cambios radicales" a la "rama estable actual" y poder, por ejemplo, corregir algunos errores/problemas, etc., con la versión actual. rama estable. De modo que cuando cambio de sucursal, la base de datos automáticamente se vuelve compatible con la sucursal en la que estoy actualmente. Realmente no me importan mucho los datos reales.
Realice un volcado de base de datos y controle la versión en su lugar. De esta manera es un archivo de texto plano.
Personalmente, le sugiero que mantenga tanto un volcado de datos como un volcado de esquema. De esta manera, al usar diff resulta bastante fácil ver qué cambió en el esquema de una revisión a otra.
Si está realizando grandes cambios, debe tener una base de datos secundaria en la que realice los nuevos cambios de esquema y no tocar la anterior ya que, como dijo, está haciendo una rama.
Estoy empezando a pensar en una solución realmente simple, ¡¡no sé por qué no se me ocurrió antes!!
- Duplicar la base de datos (tanto el esquema como los datos).
- En la rama de nuevos cambios importantes, simplemente cambie la configuración del proyecto para usar la nueva base de datos duplicada.
De esta manera puedo cambiar de rama sin preocuparme por los cambios en el esquema de la base de datos.
EDITAR:
Por duplicado me refiero a crear otra base de datos con un nombre diferente (como my_db_2); no hacer un volcado ni nada por el estilo.
- Irmin (ramificación + viaje en el tiempo)
- Flur.ee (inmutable + viaje en el tiempo + consulta de gráficos)
- XTDB (antes llamado 'CruxDB') (viaje en el tiempo + consulta)
- TerminusDB (inmutable + ramificación + viaje en el tiempo + consulta de gráficos)
- DoltDB (ramificación + viaje en el tiempo + consulta SQL)
- Quadrable (ramificación + verificación remota de estado)
- EdgeDB (sin viajes en tiempo real, pero migraciones derivadas del compilador después de cambios de esquema)
- Migra (diferencia para esquemas/datos de Postgres. Generación automática de scripts de migración, sincronización automática del estado de la base de datos)
- ImmuDB (inmutable + viaje en el tiempo)
Menciones honoríficas
- Neon : Postgreso alojado sin servidor (ramificación)
Utilice algo como LiquiBase, esto le permitirá mantener el control de revisión de sus archivos Liquibase. puede etiquetar cambios solo para producción y hacer que lb mantenga su base de datos actualizada para producción o desarrollo (o cualquier esquema que desee).
