Personnellement, je ne pense pas que ce soit une bonne idée d’utiliser un système de contrôle de source pour stocker les fichiers de sauvegarde, car le contrôle de version GIT est conçu pour les fichiers de données, pas pour les fichiers binaires ou les fichiers de vidage comme un fichier de sauvegarde MySQL. Le fait que vous puissiez le faire ne signifie pas automatiquement que vous devriez le faire. De plus, votre référentiel, qui envisage une nouvelle sauvegarde de base de données pour chaque nouvelle validation, augmentera considérablement, en utilisant beaucoup d'espace disque et les performances de GIT seront affectées, ce qui ralentira le système de contrôle de source. Pour moi, il n’est pas difficile d’exécuter une stratégie de sauvegarde et de toujours préparer un fichier de sauvegarde lorsque vous devez restaurer la base de données lorsque quelque chose ne va pas dans votre code, mais que les outils de contrôle de source ne sont pas conçus pour stocker des données binaires.
Pour ces raisons, je ne vois aucun utilitaire dans le stockage des fichiers de sauvegarde pour le jour 1 et pour le jour 2, puis pour voir les différences entre les deux fichiers de sauvegarde. Cela nécessitera beaucoup de travail supplémentaire et inutile. Au lieu d’utiliser GIT pour stocker les sauvegardes de la base de données lorsque vous validez du nouveau code, stockez les sauvegardes de la base de données dans un chemin différent, séparées par la date et l’heure, et insérez dans votre code une référence aux nouvelles sauvegardes de la base de données créées pour chaque version à l’aide des balises. comme quelqu'un l'a déjà suggéré.
Ma dernière note sur les sauvegardes de base de données et GIT: Un administrateur de base de données, lorsqu'il a besoin de restaurer une base de données car certaines données ont été perdues, n'a pas besoin de vérifier les différences entre le fichier de sauvegarde pour le jour 1 et le fichier de sauvegarde pour le jour 2, il a juste besoin de savoir quelle est la dernier fichier de sauvegarde qui lui permettra de restaurer la base de données, sans erreur ni perte de données, réduisant ainsi les temps d'arrêt. En effet, la tâche d'un administrateur de base de données est de rendre les données disponibles pour la récupération le plus rapidement possible, lorsque le système échoue pour certaines raisons. Si vous stockez les sauvegardes de la base de données dans GIT, liées à vos validations, vous n'autorisez pas l'administrateur de la base de données à restaurer les données rapidement, car vos sauvegardes sont limitées aux instants que vous avez stockés dans le référentiel GIT et à réduire les temps d'arrêt. du système,
Ensuite, je ne recommande pas de stocker les sauvegardes à l’aide de GIT, mais d’utiliser une bonne solution logicielle de sauvegarde (il en existe certaines ici ), qui offrira une plus grande granularité et vous permettra de conserver vos données en toute sécurité. récupération de données simple et rapide en cas de sinistre.