Django：如何妥善维护与上游不一致的本地迁移集

方案1：用独立编号前缀+明确依赖规避冲突 #

• 给本地迁移设置专属编号前缀，比如999_（上游通常用连续递增数字，预留高位段给本地迁移），彻底避免编号重叠问题。
• 在本地迁移的dependencies中明确依赖上游最新的迁移记录，示例：

  dependencies = [
      ('原应用名', '0015_上游最新迁移'),
  ]
  

  每次上游更新后，仅需修改本地迁移的依赖项为新的上游迁移编号，无需改动自身迁移编号，Django会自动识别执行顺序，不会触发状态冲突。

方案2：合并迁移+伪应用（适合少量本地修改） #

如果本地迁移只是对原模型的轻量修改，可定期合并上游与本地迁移：

1. 备份django_migrations表，防止操作失误丢失状态。
2. 临时移除本地迁移文件，执行python manage.py migrate --fake-initial，让Django标记所有上游迁移为已应用。
3. 基于最新上游代码重新生成本地迁移，用python manage.py migrate --fake标记历史本地修改为已应用，最后执行新的本地迁移。

方案3：用数据库视图/触发器绕开迁移系统 #

若本地需求是新增查询字段、调整数据逻辑这类非核心模型结构变更，可完全绕过Django迁移：

• 编写自定义Django管理命令，在部署阶段执行创建视图或触发器的SQL语句。
• 在原模型中通过自定义Manager或模型方法封装对视图的查询，保持代码调用的一致性。

方案4：fork上游仓库维护自定义分支 #

直接fork上游仓库，在私有分支中维护本地迁移与上游更新的合并：

• 上游发布新迁移时，拉取上游代码到本地分支，手动解决迁移冲突（调整依赖或合并迁移内容）。
• 部署时直接使用自己的fork分支，迁移系统可正常工作，无需额外处理编号问题。

独立应用方案的修正 #

如果之前尝试独立应用失败，大概率是未正确关联原应用模型：

• 在独立应用的迁移中，通过apps.get_model('原应用名', '目标模型名')引用原模型，而非直接导入。
• 给独立应用的迁移设置依赖原应用的最新迁移，示例：

  dependencies = [
      ('原应用名', '0015_上游最新迁移'),
  ]
  
  operations = [
      migrations.AddField(
          model_name='目标模型名',
          name='自定义字段',
          field=models.CharField(max_length=100, blank=True),
          preserve_default=False,
      ),
  ]
  

  这样独立应用的迁移就能正确作用于原应用的模型。

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