Citant la documentation sur les migrations Django :
Les fichiers de migration de chaque application se trouvent dans un répertoire de «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 devriez les faire une fois sur votre machine de développement, puis exécuter les mêmes migrations sur les machines de vos collègues, vos machines de préparation et éventuellement vos machines de production.
Si vous suivez ce processus, vous ne devriez pas avoir de conflits de fusion dans les fichiers de migration.
Lors de la fusion de branches de contrôle de version, vous pouvez toujours rencontrer une situation dans laquelle vous avez plusieurs migrations basées sur la même migration parent, par exemple si à différents développeurs ont introduit une migration simultanément. Une façon de résoudre cette situation est d'introduire une _merge_migration_. Cela peut souvent être fait automatiquement avec la commande
./manage.py makemigrations --merge
qui introduira une nouvelle migration qui dépend de toutes les migrations de tête actuelles. Bien sûr, cela ne fonctionne que lorsqu'il n'y a pas de conflit entre les migrations principales, auquel cas vous devrez résoudre le problème manuellement.
Étant donné que certaines personnes ici ont suggéré de ne pas valider vos migrations vers le contrôle de version, j'aimerais développer les raisons pour lesquelles vous devriez réellement le faire.
Tout d'abord, vous avez besoin d'un enregistrement des migrations appliquées à vos systèmes de production. Si vous déployez des modifications en production et souhaitez migrer la base de données, vous avez besoin d'une description de l'état actuel. Vous pouvez créer une sauvegarde distincte des migrations appliquées à chaque base de données de production, mais cela semble inutilement fastidieux.
Deuxièmement, les migrations contiennent souvent du code manuscrit personnalisé. Il n'est pas toujours possible de les générer automatiquement avec ./manage.py makemigrations
.
Troisièmement, les migrations doivent être incluses dans la révision du code. Ce sont des changements importants dans votre système de production, et il y a beaucoup de choses qui peuvent mal tourner avec eux.
Bref, si vous vous souciez de vos données de production, veuillez vérifier vos migrations vers le contrôle de version.
makemigrations some_app
, non seulement les modèles sous le contrôle de ce membre seront affectés, mais également d'autres modèles associés seront également affectés. Autrement dit, les fichiers de migration (00 * _ *) dans d'autres applications seront modifiés. Et cela provoque de nombreux problèmes de conflit lors de la poussée ou de l'extraction de GitHub. Comme actuellement notre système n'est pas prêt pour la production, nous n'avons que.gitignore
le fichier de migration. Nous ne savons toujours pas comment le résoudre lorsque le système entre en production. Quelqu'un a-t-il des solutions?