Un poco de información: usamos el contenedor docker para ejecutar nuestro proyecto django y, dado que varios de nosotros trabajamos en el proyecto, hemos colocado la carpeta de migrations en gitignore (si esto es correcto o incorrecto es un asunto aparte) para evitar conflictos de fusión.

Cada vez que se ejecutan makemigrations , siempre es 001_initial.py ya que Docker copia el proyecto git que no tiene migrations . Depende del comando de migrate determinar qué cambios aplicar a la base de datos. Se está convirtiendo en un problema común ahora que, a veces, cuando hay un campo nuevo (o un campo renombrado), aunque estos cambios están en myapp\migrations\001_initial.py , una vez que se ejecuta el comando de migrate , Django piensa que esos cambios ya están en la base de datos y no aplica ninguna migración. Estamos limpiando la base de datos y rehaciendo las migraciones, lo que funciona bien para el desarrollo, pero obviamente no funciona para la producción. Hay preguntas relacionadas con esto y se recomienda a las personas que vuelvan a las migraciones anteriores, lo que parece restablecerse y funcionó para nosotros en algunas ocasiones, por ejemplo:

 python manage.py migrate myapp zero

Pero no siempre funciona si hay relaciones en la base de datos con tablas completamente nuevas (por lo que Django se queja de que la tabla no existe) al intentar revertir y en parte porque nuestras migraciones en el contenedor docker siempre comienzan desde 001_initial.py .

¿Es esto un error de django o no estamos siguiendo ninguna buena práctica, de ahí el problema? Estamos pensando en eliminar la carpeta de migrations de gitignore , lo que permite volver a migraciones anteriores; sin embargo, no estamos completamente seguros de si esto solucionaría el problema y, además, el proyecto django se ejecuta en el contenedor, por lo que los archivos de migrations dentro del contenedor no están comprometidos con git repo. .