Django迁移损坏时如何清理旧迁移文件仅保留最新状态

完全可以实现每个app的migrations目录仅留存1份对应数据库最终状态迁移文件的目标，但粗暴删除全量迁移文件的操作仅适用于可完全删库重建的环境，生产环境必须用Django官方的迁移压缩方案平滑过渡，不会影响线上数据。

开发环境重建操作（无备份、可删库场景） #

开发环境迁移状态混乱且无数据库备份时，直接按以下步骤重建即可：

• 清空所有app下migrations目录内的文件，仅保留__init__.py
• 删除损坏的开发库，新建空的同名数据库
• 执行manage.py makemigrations，此时会为每个app自动生成1份匹配当前模型最终状态的初始迁移文件（通常命名为0001_initial.py）
• 执行manage.py migrate完成表结构同步，开发环境即可恢复正常使用。

警告：上述操作会清空所有数据库数据，绝对不能直接在生产环境执行，否则会造成不可逆的线上故障。

生产环境平滑迁移操作（不可删库场景） #

要在生产环境实现单迁移文件留存，必须通过迁移压缩流程操作，全程无停机风险：

• 本地拉取最新生产代码分支，对每个app分别执行manage.py squashmigrations <app_label> <该app最新迁移的编号>，命令会自动将该app下从首个迁移到指定编号的所有迁移逻辑合并为1个新的迁移文件，自动处理依赖关系，同时兼容已执行过所有历史迁移的存量数据库
• 将生成的压缩迁移文件提交代码，按正常发布流程部署到生产环境，执行manage.py migrate，Django会自动识别压缩迁移和历史迁移的映射关系，不会重复执行已经在生产库生效的变更
• 确认所有环境（开发、测试、生产）都已成功执行完压缩迁移后，即可删除所有零散的旧迁移文件，仅保留压缩后的单份迁移文件，后续新增的模型变更将基于该文件按顺序生成新迁移即可。

• 如果历史迁移中存在手动编写的RunPython、RunSQL逻辑，压缩后需要手动检查新迁移文件的逻辑，确保这类自定义操作不会重复执行或遗漏
• 压缩迁移部署到全环境并完成migrate操作前，不要提前删除旧迁移文件，否则会导致未完成迁移的环境出现依赖缺失报错
• 压缩迁移落地后，生产库django_migrations表中留存的旧迁移记录可以按需清理，不做清理也不会影响后续迁移的正常运行。

内容的提问来源于stack exchange，提问作者Philipp S.