大型Django项目Git管理migrations文件的最佳实践咨询

方案可行性前置结论 #

你设想的「本地仓库追踪、远程仓库忽略migrations文件」方案不可行。Git的忽略规则逻辑为：.gitignore仅对未被Git追踪的文件生效，只要文件曾被提交到仓库、纳入追踪范围，即使后续加入.gitignore，Git依然会检测该文件的本地改动、且会同步到远程仓库，无法实现两端差异化的追踪规则。

可落地的标准化协作方案 #

第一步：恢复migrations文件的追踪规则 #

• 先将migrations相关规则从.gitignore中移除，恢复该类文件的Git追踪能力
• 若之前的迁移历史已经丢失，可基于当前稳定版本重新生成基准迁移：
  1. 所有开发者先将本地数据库的现有迁移全部应用完成
  2. 删除所有app下migrations目录中的非__init__.py文件
  3. 执行python manage.py makemigrations生成全新的基准迁移文件
  4. 将基准迁移提交到远程主分支，所有开发者同步最新代码

第二步：制定团队迁移提交规范，从根源避免冲突 #

• 开发者每次修改模型前，必须先拉取最新的远程代码，确保本地migrations目录和远程完全一致后，再执行makemigrations生成新的迁移文件，禁止随意删除历史迁移文件
• 迁移文件必须和对应的模型修改代码绑定提交，不允许单独提交迁移文件
• 出现迁移冲突时优先用官方工具解决：将本地生成的迁移文件序号调整为当前最大序号+1后，执行python manage.py makemigrations --merge，Django会自动合并迁移规则，极少数自动合并失败的场景，再和产生冲突的开发者核对模型修改逻辑、手动调整迁移文件即可

第三步：适配独立开发环境的配套规则 #

• 保留每位开发者独立本地数据库的配置，开发环境测试数据无需同步
• 切换Git分支后，先执行python manage.py migrate应用对应分支的迁移规则即可，若出现迁移不兼容的情况，可直接清空重建本地开发数据库，不影响协作流程

第四步：满足版本升级需求 #

• 正式环境的迁移完全以远程仓库的迁移文件为准，打版本Tag时同步包含对应版本的migrations文件，跨版本升级时直接使用Tag内的迁移文件执行migrate操作即可

现有问题的临时修复方案 #

当前切换分支自动删除本地migrations文件的问题，可通过以下操作解决：
执行git rm --cached */migrations/*将已追踪的迁移文件从Git缓存中移除，提交该修改后，后续切换分支就不会自动删除本地的迁移文件。该方案仅作为过渡使用，长期仍建议采用上述标准化协作流程。

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