Для приложения должен быть только один каталог миграции. Ваш процесс управления релизами должен быть более устойчивым, чтобы предотвратить перезапись миграций. Это может быть замечено в обзорах кода, прежде чем код будет объединен с master или какой-либо другой веткой стабильного типа. Рецензент должен заметить удаление миграции и поднять проблему.
Теперь о том, как вы управляете тестовой базой данных, когда несколько разработчиков проводят разные и потенциально конфликтующие миграции. Вам нужно общение в команде и внимание к деталям. В 95% случаев миграция должна быть обратимой. Если миграция не выполняется, этот разработчик должен сообщить об этом другим разработчикам, которые собираются запустить и будут контролировать его до тех пор, пока A) не развернут или B) тестовая база данных не будет разобрана с производства или восстановлена из резервной копии перед миграция.
Другая часть коммуникации - это определение того, кто принимает тестовую среду, и определение наличия примененных миграций, которых нет в вашей ветви. Прежде чем развернуть вашу ветку, вам нужно отменить эти другие миграции. Тогда вы можете развернуть свой код и запустить миграцию. Вот почему обратимые миграции чрезвычайно важны.
Сложная часть - это когда миграции действительно объединяются с мастером, любая разработка, которая имеет миграции, зависящие от недавно слитых приложений миграции, должна быть объединена с помощью makemigrations --merge или они могут быть переименованы в счетчик и исправлены их зависимости.
Если для вашей организации трудно сделать это с помощью неписаных правил, то, похоже, вам нужно реализовать более жесткий процесс вокруг ваши релизы. Получение вашей базы данных из синхронизации c с миграциями может быть сложной проблемой для решения. Это особенно усугубляется, когда он находится в производственной базе данных и вызывает проблемы у клиентов. Ваша организация должна эффективно управлять своими рисками с помощью управления выпусками.