Django部署到PythonAnywhere出现Migrations迁移树损坏如何解决

问题普遍性说明 #

该问题是Django开发的常见通用问题，和部署平台无关，除PythonAnywhere外，所有部署环境包括VPS、容器集群、其他PaaS服务只要不符合Django迁移文件的管理规范，都会触发同类问题。

问题核心触发原因 #

你当前的操作流程存在错误：生产环境不应该执行makemigrations命令。
Django的迁移文件属于代码的一部分，makemigrations只能在本地开发环境执行，生成的序列文件需要和业务代码一起提交到GitHub，服务端拉取代码后仅需执行migrate命令应用已有的迁移即可。你在服务端执行makemigrations会生成和本地序列冲突的迁移文件，直接导致迁移树断裂报错。

标准修复&规避方案 #

日常操作规范 #

• 本地开发阶段：每次修改models.py后，本地执行python manage.py makemigrations，确认生成的迁移文件逻辑正确后，和业务代码一并提交到代码仓库，禁止修改已经提交过的迁移文件
• 服务端部署阶段：拉取最新代码后，仅执行python manage.py migrate即可，永远不要在生产环境执行makemigrations
• 不要在.gitignore中添加任意app下migrations目录的匹配规则，仅可忽略该目录下的__pycache__缓存文件，所有.py后缀的迁移文件必须全部提交

现有冲突无风险修复步骤 #

1. 先备份服务端SQLite数据库，直接复制db.sqlite3文件到独立目录完成备份
2. 确认本地所有app的migrations目录下的迁移文件全部提交到GitHub，保证服务端拉取代码后的migrations目录和本地完全一致
3. 服务端执行python manage.py showmigrations查看当前已应用的迁移标记，对齐本地迁移序列
4. 若存在序列冲突报错，执行python manage.py migrate --fake <对应app名> <最后一个正常的迁移编号>将迁移标记对齐到正确序列，再执行常规migrate命令即可完成修复，该操作不会修改现有业务数据，无丢失风险

内容的提问来源于stack exchange，提问作者Jorge Armando Molano Prada