Comment puis-je mettre une base de données sous git (contrôle de version)?

Question

Je suis en train de faire une application web, et j'ai besoin de faire une branche des changements majeurs, la chose est, ces changements nécessitent des modifications au schéma de base de données, donc je voudrais mettre l'ensemble de la base de données sous git.

Comment dois-je faire? est-il un dossier spécifique que je peux garder en vertu d'un dépôt git? Comment puis-je savoir laquelle? Comment puis-je être sûr que je suis en train de mettre le bon dossier?

J'ai besoin d'être sûr, parce que ces changements ne sont pas compatibles; je ne peux pas se permettre de visser.

La base de données dans mon cas, c'est PostgreSQL

Edit:

Quelqu'un a suggéré de prendre des sauvegardes et de mettre le fichier de sauvegarde sous contrôle de version à la place de la base de données. Pour être honnête, je trouve cela vraiment difficile à avaler.

Il y a une meilleure façon.

Mise à jour:

OK, donc il ya pas de meilleure façon, mais je ne suis pas encore tout à fait convaincu, donc je vais un peu changer ma question:

J'aimerais mettre l'ensemble de la base de données sous contrôle de version, ce moteur de base de données puis-je utiliser afin que je puisse mettre la base de données sous contrôle de version à la place de son dump?

Serait sqlite être git de l'environnement?

Depuis ce n'est que l'environnement de développement, je peux choisir la base de données que je veux.

Edit2:

Ce que je veux vraiment, c'est de ne pas suivre mon évolution de l'histoire, mais pour être en mesure de passer de mon "nouveaux changements radicaux" branche "stable actuelle de la branche" et être en mesure, par exemple pour corriger quelques bugs/problèmes, etc, avec la branche stable. Tels que, lorsque je change de branches, la base de données de l'auto-magiquement devient compatible avec la branche, je suis actuellement sur. Je n'ai pas vraiment beaucoup de soins sur les données réelles.

Answer 1

Prenez un vidage de base de données et un contrôle de version à la place. De cette façon, il s'agit d'un fichier texte plat.

Personnellement, je suggère que vous gardiez à la fois un vidage de données et un vidage de schéma. De cette façon, en utilisant diff, il devient assez facile de voir ce qui a changé dans le schéma de la révision à la révision.

Si vous effectuez de gros changements, vous devriez avoir une base de données secondaire dans laquelle vous modifiez le nouveau schéma et ne touchez pas à l'ancienne puisque, comme vous l'avez dit, vous créez une branche.

Answer 2

Découvrez la Refactorisation de Bases de données (http://databaserefactoring.com/) pour un tas de bonnes techniques pour la maintenance de votre base de données en tandem avec les changements de code.

Il suffit de dire que vous vous posez les mauvaises questions. Au lieu de mettre votre base de données dans le dépôt git, vous devriez être en décomposition vos modifications en petits vérifiables étapes, de sorte que vous pouvez migrer/annulation des modifications de schéma avec facilité.

Si vous voulez avoir la pleine capacité de récupération, vous devriez envisager l'archivage de vos postgres WAL journaux et utiliser le PITR (point dans le temps de récupération) pour lire/opérations de change à terme spécifiques connu un bon état.

Answer 3

Je commence à penser que d'une solution simple, ne sais pas pourquoi je n'avais pas pensé avant!!

• Dupliquer la base de données (à la fois sur le schéma et les données).
• Dans la branche de la nouvelle-major des modifications, il suffit de modifier la configuration du projet pour utiliser la nouvelle base de données en double.

De cette façon, je peux passer des branches sans se soucier de schéma de base de données change.

EDIT:

En double, je veux créer une autre base de données avec un nom différent (comme my_db_2); ne pas faire un dump ou quelque chose comme ça.

Answer 4

Utilisez quelque chose comme LiquiBase cela vous permet de garder le contrôle des versions de vos fichiers Liquibase. vous pouvez étiqueter les modifications pour la production uniquement, et vous devez garder votre base de données à jour pour la production ou le développement (ou tout autre système que vous voulez).

Answer 5

Au lieu de saisir manuellement le dumping votre base de données et l'enregistrer dans le dépôt git, utilisez Offscale DataGrove.

DataGrove est essentiellement une version DB contrôle - il suit les modifications apportées à l'ensemble de la DB (schéma et les données) ET vous permet de marquer versions du référentiel. Vous pouvez l'utiliser avec git et avoir une balise de version à chaque fois que vous vérifiez le code, et de charger la droite DB état à chaque fois que vous tirez de code.

En ce qui concerne spécifiquement "Edit 2" - avec DataGrove vous pouvez tout simplement avoir les deux branches de la DB, un pour chacun de vous de branches de code. Lorsque vous chargez une certaine branche de la code, DataGrove sera automatiquement re-créer l'ensemble de la DB de l'état, avec toutes les données à l'intérieur de cette version ou de la direction. Cela signifie que vous pouvez basculer entre les branches de développement avec une simple commande.