多人同分支协作时，Django迭代迁移的正确管理方法

核心场景 #

在Django项目的同一开发分支中，多人迭代同一模型并生成迁移文件，需要规范同步变更并执行迁移，避免数据库结构与迁移记录不一致的问题。

正常同步迁移的标准流程 #

• 拉取分支最新代码：

  git pull origin your-branch-name
  

• 确认拉取到完整的迁移文件：检查项目app_name/migrations/目录，确保其他开发者提交的迁移文件已同步到本地
• 执行迁移，将变更同步到本地数据库：

  python manage.py migrate
  

• 若本地有未提交的模型修改：
  1. 先通过git stash暂存本地修改，或提交本地变更到分支
  2. 拉取远程最新代码后，再基于最新模型生成新的迁移文件：

     python manage.py makemigrations app_name
     

  3. 将新生成的迁移文件提交并推送到远程分支，供其他开发者同步

针对「Relation 'foo' already exists」错误的修复步骤 #

你遇到的错误是因为Django的迁移记录与数据库实际结构不匹配（数据库中已存在目标表/列，但迁移记录未标记为已应用），可按以下步骤修复：

1. 查看当前应用的迁移状态，确认哪些迁移已执行、哪些未执行：

   python manage.py showmigrations app_name
   

   标记[X]的是已应用的迁移，无标记的是待执行的。

2. 找到报错对应的迁移文件（比如0003_foo.py），将其标记为已应用但不实际修改数据库（因为表已经存在）：

   python manage.py migrate --fake app_name 0003
   

   这里的0003是迁移文件的前缀编号，替换为你实际的迁移文件编号。

3. 执行剩余的迁移，完成所有变更同步：

   python manage.py migrate app_name
   

错误操作纠正 #

• 不要手动删除迁移文件：迁移文件是Django追踪数据库变更历史的核心依据，删除会直接导致迁移记录与数据库结构脱节
• makemigrations --merge仅用于解决分支合并时的迁移冲突，同一分支下不存在合并场景，因此会提示无内容可合并
• 单独使用migrate --fake只会修改迁移记录，不会同步实际数据库变更，必须配合实际迁移步骤使用

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