¿Debería agregar los archivos de migración de Django en el archivo .gitignore?

¿Debería agregar los archivos de migración de Django en el .gitignorearchivo?

Recientemente, he tenido muchos problemas de git debido a conflictos de migración y me preguntaba si debería marcar los archivos de migración como ignorados.

Si es así, ¿cómo podría agregar todas las migraciones que tengo en mis aplicaciones y agregarlas al .gitignorearchivo?

Citando de la documentación de migraciones de Django :

Los archivos de migración de cada aplicación se encuentran en un directorio de "migraciones" dentro de esa aplicación y están diseñados para comprometerse y distribuirse como parte de su código base. Debería hacerlos una vez en su máquina de desarrollo y luego ejecutar las mismas migraciones en las máquinas de sus colegas, sus máquinas de preparación y, finalmente, sus máquinas de producción.

Si sigue este proceso, no debería tener ningún conflicto de fusión en los archivos de migración.

Al fusionar ramas de control de versiones, aún puede encontrar una situación en la que tenga varias migraciones basadas en la misma migración principal, por ejemplo, si diferentes desarrolladores introdujeron una migración al mismo tiempo. Una forma de resolver esta situación es introducir una _merge_migration_. A menudo, esto se puede hacer automáticamente con el comando

./manage.py makemigrations --merge

que introducirá una nueva migración que depende de todas las migraciones de cabeza actuales. Por supuesto, esto solo funciona cuando no hay conflicto entre las migraciones de cabezales, en cuyo caso tendrá que resolver el problema manualmente.

Dado que algunas personas sugirieron que no debería enviar sus migraciones al control de versiones, me gustaría ampliar las razones por las que debería hacerlo.

Primero, necesita un registro de las migraciones aplicadas a sus sistemas de producción. Si implementa cambios en producción y desea migrar la base de datos, necesita una descripción del estado actual. Puede crear una copia de seguridad separada de las migraciones aplicadas a cada base de datos de producción, pero esto parece innecesariamente engorroso.

En segundo lugar, las migraciones suelen contener código escrito a mano personalizado. No siempre es posible generarlos automáticamente con ./manage.py makemigrations.

En tercer lugar, las migraciones deben incluirse en la revisión del código. Son cambios significativos en su sistema de producción y hay muchas cosas que pueden salir mal con ellos.

En resumen, si le preocupan sus datos de producción, verifique sus migraciones al control de versiones.

Puede seguir el siguiente proceso.

Puede ejecutar makemigrationslocalmente y esto crea el archivo de migración. Confirme este nuevo archivo de migración en repositorio.

En mi opinión, no debería ejecutar makemigrationsen absoluto la producción. Puede ejecutar migrateen producción y verá que las migraciones se aplican desde el archivo de migración que comprometió desde local. De esta forma puede evitar todos los conflictos.

EN LOCAL ENV , para crear los archivos de migración,

python manage.py makemigrations 
python manage.py migrate

Ahora confirme estos archivos recién creados, algo como a continuación.

git add app/migrations/...
git commit -m 'add migration files' app/migrations/...

EN PRODUCTION ENV , ejecute solo el siguiente comando.

python manage.py migrate

Cita de los documentos de 2018, Django 2.0. (dos comandos separados = makemigrationsy migrate)

La razón por la que existen comandos separados para realizar y aplicar migraciones es porque enviará las migraciones a su sistema de control de versiones y las enviará con su aplicación; no solo facilitan su desarrollo, también son utilizables por otros desarrolladores y en producción.

https://docs.djangoproject.com/en/2.0/intro/tutorial02/

TL; DR: compruebe migraciones, resuelva conflictos de migración, ajuste su flujo de trabajo de git.

Parece que necesita ajustar su flujo de trabajo de git , en lugar de ignorar los conflictos.

Idealmente, cada característica nueva se desarrolla en una rama diferente y se fusiona con una solicitud de extracción .

Los RP no se pueden fusionar si hay un conflicto, por lo tanto, quien necesita fusionar su función debe resolver el conflicto, incluidas las migraciones. Esto podría necesitar coordinación entre diferentes equipos.

¡Sin embargo, es importante confirmar los archivos de migración! Si surge un conflicto, Django incluso podría ayudarlo a resolver esos conflictos ;)

No puedo imaginar por qué tendría conflictos, a menos que esté editando las migraciones de alguna manera. Eso generalmente termina mal: si alguien pierde algunas confirmaciones intermedias, no se actualizará desde la versión correcta y su copia de la base de datos se dañará.

El proceso que sigo es bastante simple: cada vez que cambia los modelos de una aplicación, también realiza una migración, y luego esa migración no cambia ; si necesita algo diferente en el modelo, cambia el modelo y confirma una nueva migración junto con sus cambios.

En proyectos totalmente nuevos, a menudo puede eliminar las migraciones y comenzar de cero con una migración 0001_ cuando la publique, pero si tiene código de producción, entonces no puede (aunque puede reducir las migraciones en una sola).

La solución que se suele utilizar es que, antes de fusionar algo en el maestro, el desarrollador debe realizar los cambios remotos. Si hay un conflicto de versiones de migración, debe cambiar el nombre de su local, migración (la remota ha sido ejecutada por otros desarrolladores y, potencialmente, en producción), a N + 1.

Durante el desarrollo, podría estar bien simplemente no confirmar las migraciones (no agregue ignorar, simplemente no add ). Pero una vez que haya entrado en producción, los necesitará para mantener el esquema sincronizado con los cambios del modelo.

A continuación, debe editar el archivo y cambiar el dependencies a la última versión remota.

Esto funciona para las migraciones de Django, así como para otras aplicaciones similares (sqlalchemy + alambic, RoR, etc.).

Tener un montón de archivos de migración en git es complicado. Solo hay un archivo en la carpeta de migración que no debe ignorar. Ese archivo es un archivo init .py. Si lo ignora, Python ya no buscará submódulos dentro del directorio, por lo que cualquier intento de importar los módulos fallará. Entonces, la pregunta debería ser ¿cómo ignorar todos los archivos de migración excepto init .py? La solución es: agregue '0 * .py' a los archivos .gitignore y hace el trabajo perfectamente.

Espero que esto ayude a alguien.

Ignore las migraciones, si tiene bases de datos independientes para el entorno de desarrollo, preparación y producción. Para dev. propósitos Puede usar la base de datos sqlite local y jugar con migraciones localmente. Te recomendaría crear cuatro ramas adicionales:

1. Maestro: código nuevo limpio sin migraciones. Nadie está conectado a esta rama. Se usa solo para revisiones de código

2. Desarrollo - desarrollo diario. Se acepta empujar / tirar. Cada desarrollador está trabajando en sqlite DB

3. Cloud_DEV_env: entorno de DEV de servidor / nube remota. Tire solamente. Mantenga las migraciones localmente en la máquina, que se utiliza para la implementación de código y las migraciones remotas de la base de datos Dev

4. Cloud_STAG_env: entorno STAG de servidor / nube remota. Tire solamente. Mantenga las migraciones localmente en la máquina, que se utiliza para la implementación de código y las migraciones remotas de la base de datos Stag

5. Cloud_PROD_env: entorno DEV de servidor / nube remota. Tire solamente. Mantenga las migraciones localmente en la máquina, que se utiliza para la implementación de código y las migraciones remotas de la base de datos Prod

Notas: 2, 3, 4: las migraciones se pueden mantener en repositorios, pero debe haber reglas estrictas para la fusión de solicitudes de extracción, por lo que decidimos buscar una persona, responsable de las implementaciones, para que el único que tenga todos los archivos de migración: nuestra implementación -er. Mantiene las migraciones de bases de datos remotas cada vez que tenemos cambios en los modelos.

Respuesta corta Propongo excluir migraciones en el repositorio. Después de fusionar el código, simplemente ejecute ./manage.py makemigrationsy estará listo.

Respuesta larga No creo que debas poner los archivos de migraciones en repositorio. Arruinará los estados de migración en el entorno de desarrollo de otra persona y otros entornos de producción y escenario. (consulte el comentario de Sugar Tang para ver ejemplos).

En mi punto de vista, el propósito de las migraciones de Django es encontrar brechas entre los estados del modelo anterior y los estados del nuevo modelo, y luego serializar la brecha. Si su modelo cambia después de la fusión de código, puede hacerlo de forma sencilla makemigrationspara averiguar el espacio. ¿Por qué desea fusionar otras migraciones de forma manual y cuidadosa cuando puede lograr lo mismo automáticamente y sin errores? La documentación de Django dice:

Ellos * (migraciones) * están diseñados para ser principalmente automáticos

; por favor manténgalo así. Para fusionar migraciones manualmente, debe comprender completamente lo que otros han cambiado y cualquier dependencia de los cambios. Eso es mucha sobrecarga y propenso a errores. Entonces, el archivo de modelos de seguimiento es suficiente.

Es un buen tema en el flujo de trabajo. Estoy abierto a otras opciones.