Django项目克隆恢复DB后出现migrations冲突无法生成迁移文件

问题原因 #

这是Django多分支并行开发导致的典型迁移图叶节点冲突：不同开发分支各自在orders应用下生成了迁移文件，没有统一的依赖链路，导致迁移图出现两个无先后关系的最终节点（0012_remove_cart_session_id和0017_alter_placedorder_order_time），Django无法判断执行顺序，因此触发冲突报错。KeyError: 'session_id'的报错也是因为迁移执行顺序错乱，系统尝试移除不存在的字段导致的。

修复步骤 #

• 先确认本地数据库迁移状态：执行python manage.py showmigrations orders，查看所有已应用的迁移，确保本地数据库状态和你恢复的备份匹配，无异常未同步记录。
• 优先使用官方自动合并方案：执行python manage.py makemigrations --merge，Django会自动生成合并迁移文件，将两个冲突的叶节点同时设为前置依赖，把两条并行迁移链合并为一条，无需手动修改迁移内容。
• 生成合并迁移后，执行python manage.py migrate orders验证迁移是否可正常执行。
• 如果自动合并不成功（比如两个迁移修改了同一字段导致逻辑冲突），再手动处理：
  1. 备份orders应用下所有现有迁移文件
  2. 确认当前数据库表结构和代码定义一致，执行python manage.py makemigrations orders --empty生成空迁移文件
  3. 将两个冲突的叶节点都写入该空迁移的dependencies列表，operations留空即可，相当于手动完成合并
  4. 执行python manage.py migrate --fake orders [新合并迁移文件名]，仅标记该迁移为已执行，不需要实际修改表结构
• 你当前已有的那个operations为空的迁移文件就是标准的合并迁移，可先检查它的dependencies列表是否已经包含报错中提到的两个冲突叶节点，如果缺少可手动补上，直接执行fake迁移即可完成修复，不需要重新生成。

合并依赖修复原理 #

Django的迁移是有向无环图结构，每个迁移文件的dependencies字段指定了它的前置依赖，正常情况下迁移链是线性的，仅存在一个最终叶节点。
出现冲突时迁移图存在两个平行的叶节点，合并迁移的作用就是新增一个迁移节点，将两个冲突的叶节点同时设为自身的前置依赖，这样Django就知道要先执行完两个平行的迁移链，再往后执行新的迁移，让迁移图重新回到仅有一个叶节点的正常状态。
--fake参数的作用是仅更新Django记录迁移状态的django_migrations表，不实际执行SQL修改表结构，适合你这种从仓库克隆+恢复数据库备份的场景：表结构本身是正确的，只是迁移记录的链路错乱，无需修改实际表数据即可修复链路。

内容的提问来源于stack exchange，提问作者Atif Shafi