Цитата из документации по миграции Django :
Файлы миграции для каждого приложения находятся в каталоге «миграции» внутри этого приложения и предназначены для передачи и распространения как часть его кодовой базы. Вы должны сделать их один раз на своей машине разработки, а затем запустить те же миграции на машинах ваших коллег, ваших промежуточных машинах и, в конечном итоге, ваших производственных машинах.
Если вы последуете этому процессу, у вас не должно возникнуть конфликтов слияния в файлах миграции.
При объединении ветвей управления версиями вы все равно можете столкнуться с ситуацией, когда у вас есть несколько миграций, основанных на одной и той же родительской миграции, например, если разные разработчики представили миграцию одновременно. Один из способов решить эту ситуацию - ввести _merge_migration_. Часто это можно сделать автоматически с помощью команды
./manage.py makemigrations --merge
который представит новую миграцию, которая зависит от всех текущих миграций головы. Конечно, это работает только тогда, когда нет конфликта между головными миграциями, и в этом случае вам придется решать проблему вручную.
Учитывая, что некоторые люди здесь предложили вам не передавать свои миграции в систему контроля версий, я хотел бы подробнее остановиться на причинах, по которым вам действительно следует это делать.
Во-первых, вам нужна запись о миграциях, примененных к вашим производственным системам. Если вы развертываете изменения в производственной среде и хотите перенести базу данных, вам потребуется описание текущего состояния. Вы можете создать отдельную резервную копию миграций, применяемых к каждой производственной базе данных, но это кажется излишне громоздким.
Во-вторых, миграции часто содержат собственный рукописный код. Не всегда возможно автоматически сгенерировать их с помощью ./manage.py makemigrations
.
В-третьих, миграции должны быть включены в обзор кода. Это значительные изменения в вашей производственной системе, и есть много вещей, которые могут пойти не так.
Короче говоря, если вам важны производственные данные, проверьте свои миграции в системе контроля версий.
makemigrations some_app
, это затронет не только модели, находящиеся под его контролем, но и другие связанные модели. То есть файлы миграции (00 * _ *) в других приложениях будут изменены. И это вызывает множество проблем с конфликтами при отправке или извлечении из GitHub. Поскольку в настоящее время наша система не готова к производству, мы просто.gitignore
файл миграции. Мы до сих пор не знаем, как решить эту проблему, когда система будет запущена в производство. Есть ли у кого-нибудь решения?