Django REST迁移文件提交至生产环境的冲突问题与解决问询

问题1：推送本地迁移文件到生产是否会冲突？ #

取决于本地和生产的两个0011_user_isActive.py内容是否完全一致：

• 内容完全一致：不会冲突。生产环境的django_migrations表已经记录该迁移已执行，Django会识别文件匹配，后续执行migrate时会直接跳过，不会重复执行操作。
• 内容存在差异：会触发冲突。比如字段默认值、操作逻辑不同时，Django会检测到迁移记录与文件不匹配，可能抛出错误，甚至导致数据库结构异常。

问题2：修复当前局面的步骤 #

第一步：确认迁移文件一致性 #

先登录生产服务器，找到app/migrations/0011_user_isActive.py，与本地的同文件逐行对比，确保内容（迁移操作、依赖关系、字段定义）完全一致。

情况A：文件内容完全一致 #

1. 本地提交迁移文件到版本库：

git add app/migrations/0011_user_isActive.py
git commit -m "add migration for user isActive field"
git push

2. 生产服务器拉取最新代码：

git pull

3. 执行migrate验证状态（此时Django会提示迁移已完成，无额外操作）：

python manage.py migrate

情况B：文件内容不一致 #

这种情况必须以生产已执行的迁移为准，避免破坏生产数据库结构：

1. 从生产服务器下载0011_user_isActive.py，替换本地的同文件。
2. 本地提交替换后的文件：

git add app/migrations/0011_user_isActive.py
git commit -m "sync migration with production: user isActive field"
git push

3. 生产服务器拉取代码，完成三方（本地、代码库、生产）迁移文件同步。

迁移操作最佳实践 #

• 绝对禁止在生产环境执行makemigrations：迁移文件必须在本地开发环境生成，测试通过后提交到版本控制，生产仅执行migrate命令。
• 迁移文件必须纳入版本控制：每次生成迁移后，立即提交对应的migrations目录下的新文件，确保本地、代码库、生产环境的迁移文件完全同步。
• 生产迁移前必须备份数据库：使用PostgreSQL的pg_dump命令备份全库，示例：

pg_dump -U 数据库用户名 -d 数据库名 > 备份文件名.sql

备份完成后再执行migrate，避免迁移出错导致数据丢失。

• 用 staging 环境预测试：搭建与生产配置一致的 staging 环境，每次部署前先在staging执行迁移，验证无误后再部署到生产。
• 避免手动修改迁移文件：如果需要调整迁移逻辑，优先通过修改模型重新生成迁移，而非手动编辑已生成的迁移文件，防止出现逻辑不一致。

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