makemigrations --merge 不能自动解决冲突，仅生成空合并文件，需手动确认模型兼容性并编辑 operations；真实冲突源于模型状态与迁移历史错位，应重命名迁移、手工合并再提交。
makemigrations --merge 能自动解决冲突吗
不能。它只生成一个空的合并迁移文件，不自动修复逻辑冲突，也不检查模型状态是否一致。你得手动确认两个分支的模型变更是否兼容，再编辑生成的迁移文件补全 operations。
常见错误现象：执行 python manage.py makemigrations --merge 后生成了 0003_merge_abc123.py，但里面 operations = []，且 dependencies 列了两个父迁移——这时 Django 认为“需要合并”，但没能力判断该加字段还是删字段。
- 只有当两个分支都基于同一个父迁移（比如都从
0002_auto...分出），且没有互相覆盖的模型修改时，--merge才安全 - 如果 feature-a 删除了
name字段，feature-b 又给name改了max_length，合并迁移必须人工写RemoveField和AlterField的先后顺序，否则 migrate 会报错 - 生成后务必用
python manage.py sqlmigrate app_name 0003_merge_abc123预览 SQL，确认没有冲突语句（比如对同一字段反复 ALTER）
多人协作中迁移冲突的真实来源
冲突不是 Git 合并时才出现的，而是模型状态和迁移历史错位导致的。典型场景：
- 开发者 A 在 branch-1 中改了
models.py，运行makemigrations得到0003_add_status.py，但没提交就切走了 - 开发者 B 在 branch-2 中同样改了
models.py，也生成了0003_add_status.py（编号相同但内容不同） - 两人各自提交、推送，别人拉取后
showmigrations会显示两个0003都是未应用状态，但 Django 只能按文件名顺序执行一个
这时 --merge 不是首选。更稳妥的做法是：先统一重命名其中一方的迁移文件为 0004_...，再手工比对两个 0003 的 operations，把差异合并进新文件，最后删掉旧的两个 0003。
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
为什么 --fake-initial 不该用来绕过迁移冲突
--fake-initial 只在一种场景下合法：项目已有数据库表结构，但还没接入 Django 迁移系统。它会跳过所有 initial 迁移的执行，仅标记为已应用。
把它用在冲突场景里，等于告诉 Django “别管这些迁移文件，我数据库自己心里有数”——但实际没人心里有数。后果包括：
- 后续迁移依赖这个 initial 迁移，
dependencies断链，migrate直接报InconsistentMigrationHistory - 团队其他成员执行
migrate时，因为他们的数据库没表，--fake-initial不生效，又回到报错原点 - SQLite 下尤其危险：路径错位或文件锁残留会让
--fake-initial成功“骗过”Django，但表根本不存在
真正有效的冲突修复流程
别碰 django_migrations 表，也别删整个 migrations/ 目录。按顺序做三件事：
- 先跑
python manage.py showmigrations，确认哪些迁移标了[ ]（待执行）、哪些标了[X]（已记录）但表实际缺失 - 对“已记录但表缺失”的迁移，用
python manage.py sqlmigrate app_name 0002_xxx看输出。如果报错或无输出，说明迁移文件损坏，删掉它和所有编号更大的未应用迁移文件 - 删完后，确保当前
models.py是最终期望状态，再跑python manage.py makemigrations——这次生成的是干净、线性、无分支痕迹的新迁移
最易被忽略的一点：修复后必须立刻提交新迁移文件，并通知团队成员删除本地对应应用的 migrations/ 下所有未提交的迁移文件，否则下次拉代码还会冲突。
