Краткий ответ : Вы можете сделать это, но вы должны быть осторожны и учитывать некоторые ситуации.
Вы можете удалить миграции, которые еще не применены к базе данных.Но вы должны быть очень осторожны с этим, поскольку не сказано, что если миграции не применяются к одной базе данных (например, к базе данных, которую вы используете для разработки), то другие базы данных (например, в рабочей среде) уже не переносятся в дальнейшем.цепочка миграции.
Таким образом, вы должны удалять только те миграции, для которых вы уверены, что ни одна база данных еще не выполнила миграции.Если вы удалили миграции, которые уже были применены.Например, базы данных могут иметь уже созданные таблицы, столбцы и т. Д. Если вы позже запустите новую миграцию, эта миграция будет содержать изменения, начиная с той точки, где вы удалили миграции, и, следовательно, может привести к ошибкам, поскольку эта миграциябудет стремиться создать таблицу, которая уже существует.
Другая потенциальная проблема заключается в том, что миграции могут содержать RunPython операций [Django-doc] .Обычно это небольшие кусочки кода, которые каждый вставил вручную .Например, заменить все записи так, чтобы конкретный столбец теперь имел определенное значение.При удалении этих миграций и новых миграциях эти RunPython операции будут потеряны.Название миграций (оно содержит auto) предполагает, что миграции были созданы автоматически, но не исключено, что программист позже изменил такой файл и таким образом вставил операцию RunPython.
Имеямножественные миграции не являются серьезной проблемой.Django запустит алгоритм топологической сортировки на «графе миграции», и это можно сделать в O (n) .Наличие большого количества файлов обычно не является серьезным узким местом.
Возможно, вы захотите использовать squashmigrations [Django-doc] для группирования миграций вновый файл.Это будет учитывать операции RunPython и, таким образом, может быть более безопасным, чем подавление миграций путем удаления и воссоздания миграций.