如何在非master分支中规范维护Django迁移？

我之前也碰到过几乎一模一样的场景——维护一个长期不合并到master的实验分支，每次同步master的迁移都头疼得要命。下面几个方法亲测有效，你可以根据自己的情况选择：

方法1：定期“压扁”实验分支的迁移历史（最推荐） #

这是最彻底的解决方案，相当于把实验分支的所有迁移变更重新基于master的最新状态生成，彻底消除分支节点：

• 先确保实验分支的模型代码和当前业务逻辑完全一致，然后删除实验分支下所有自己新增的迁移文件（注意别误删master原有的迁移）
• 运行 python manage.py makemigrations 重新生成一个全新的迁移文件，这个文件会包含实验分支所有的模型变更，且依赖指向master最新的迁移节点
• 关键步骤：在测试环境先验证这个新迁移的正确性——可以用 python manage.py sqlmigrate <your_app> <new_migration_number> 查看生成的SQL，确认和之前的变更逻辑一致；或者直接在测试数据库运行迁移，检查数据是否正常
• 之后每次合并master的迁移后，都可以重复这个流程，让实验分支的迁移历史始终是一条基于最新master的直线，不会产生分支节点

方法2：手动调整迁移依赖，避免自动分支 #

如果不想重新生成迁移文件，可以手动修改实验分支迁移的依赖指向，跳过自动合并生成的分支节点：

• 合并master到实验分支后，找到实验分支独有的迁移文件，打开它的dependencies字段
• 把原来依赖的旧master迁移编号，替换成master最新的迁移编号（比如把['myapp.0005_old_master_migration']改成['myapp.0008_new_master_migration']）
• 保存后，运行 python manage.py migrate 就不会再出现分支节点报错了，因为实验分支的迁移现在直接基于master的最新状态
• 注意：这个方法需要你对Django迁移的依赖关系有清晰理解，别改错依赖，否则可能导致迁移逻辑混乱

方法3：用--fake命令标记master迁移为已应用 #

如果合并后只是迁移历史冲突，但实验分支的数据库其实已经包含了master迁移的变更，可以用--fake来跳过实际执行，只修正迁移状态：

• 先解决代码冲突，确保实验分支的模型代码是合并后的正确状态
• 运行 python manage.py migrate --fake，让Django把master的所有迁移标记为已应用（不会实际执行SQL，只是修改迁移历史记录）
• 删除实验分支里和master冲突的旧迁移文件，再运行 python manage.py makemigrations 生成新的迁移，这个新迁移会自动依赖master的最新节点

方法4：为实验分支单独维护数据库环境（适合超长期分支） #

如果实验分支要维护几个月甚至更久，单独的数据库环境可以彻底隔离迁移历史：

• 为实验分支配置独立的数据库（或者用不同的schema）
• 每次同步master时，先把master的所有迁移应用到这个实验数据库
• 然后基于这个已同步的数据库，为实验分支的模型变更生成新迁移，完全不会和master的迁移历史产生冲突

重要注意事项 #

• 所有操作先在测试环境验证：迁移涉及数据库，直接在生产环境操作风险极高，一定要先在测试环境跑一遍，确认数据安全
• 合并master后先对比差异：搞清楚master新增了哪些迁移，实验分支有哪些独有的变更，再动手调整迁移，避免盲目操作
• 处理代码优先：如果实验分支和master的模型变更有重叠（比如都修改了同一个字段），一定要先解决代码冲突，再处理迁移问题

内容的提问来源于stack exchange，提问作者Doug Bradshaw