python - Le répertoire Migrations du projet Django doit-il être validé dans git

Question

Comme l'indique le titre, lorsque l'environnement de développement local modifie le modèle, celui-ci change parfois plusieurs fois, puis de nombreux fichiers de migration sont générés.

Mais lors du déploiement sur le serveur, comment le serveur doit-il effectuer les modifications :

1. Ne téléchargez pas le fichier de migration, exécutez directement makemigrations 重新生成 migrations，再运行 migrate

2. Téléchargez le fichier de migrations pendant le développement puis exécutez-le directement migrate

Laquelle dois-je choisir parmi les deux méthodes ci-dessus ? Pourquoi?

Answer 1

Selon la déclaration officielle, il doit être soumis et exécuté directement côté serveur migrate sans qu'il soit nécessaire de le générer à nouveau.

Vous devez considérer les migrations comme un système de contrôle de version pour votre schéma de base de données. makemigrations est chargé de regrouper les modifications de votre modèle dans des fichiers de migration individuels - analogues aux commits - et migrate est responsable de leur application à votre base de données.

Les fichiers de migration de chaque application se trouvent dans un répertoire « migrations » à l'intérieur de cette application et sont conçus pour être validés et distribués dans le cadre de sa base de code. Vous devez les créer une fois sur votre ordinateur de développement, puis les exécuter. mêmes migrations sur les machines de vos collègues, vos machines de staging, et éventuellement vos machines de production.

Traduction chinoise :

Vous pouvez considérer les migrations comme un système de contrôle de version pour votre base de données. La commande makemigrations est chargée d'enregistrer les modifications de votre modèle dans un fichier de migration - un peu comme les validations - tandis que migrate est responsable de la validation des modifications dans la base de données.

Le fichier de migration de chaque application sera enregistré dans le dossier "migrations" de chaque application correspondante, et la manière de l'exécuter sera préparée sous forme de base de code distribuée. Vous devez recréer ces fichiers à chaque fois que vous effectuez la même migration sur votre machine de développement ou celle de votre collègue et éventuellement sur votre machine de production.

Answer 2

Il est recommandé de le soumettre au référentiel.

Answer 3

Je ne synchronise pas actuellement avec la bibliothèque distante.
Étant donné que le modèle doit être modifié fréquemment pendant le processus de développement, de nombreux fichiers de migration seront générés et il est difficile de contrôler la migration sans erreurs ;
Avant de publier le programme, vérifiez d'abord si le modèle est mis à jour ; effectuez des migrations, puis migrez. En raison de la situation locale, il a été testé, il n'est donc pas sujet à des problèmes de synchronisation étranges.

Answer 4

Pourquoi ne supprimez-vous pas les modifications nouvellement générées dans les migrations avant de soumettre, refaites les migrations, puis soumettez le référentiel

Answer 5

Mais localement, ajouter des champs puis les supprimer, etc. sont des opérations inutiles au final, il se peut qu'il n'y ait aucun changement dans la base de données. Donc ces migrations doivent également être soumises au serveur et réexécutées ?