引用Django迁移文档：
每个应用程序的迁移文件都位于该应用程序内的“迁移”目录中，并且被设计为提交至其代码库并作为其代码库的一部分进行分发。您应该在开发计算机上制作一次，然后在同事的计算机，登台计算机以及最终的生产计算机上运行相同的迁移。
如果遵循此过程，则迁移文件中不会出现任何合并冲突。
合并版本控制分支时，您仍可能会遇到基于同一父级迁移的多个迁移的情况，例如，如果不同的开发人员同时引入了迁移。解决这种情况的一种方法是引入_merge_migration_。通常这可以通过以下命令自动完成
./manage.py makemigrations --merge
这将引入一个新的迁移，该迁移取决于当前的所有head迁移。当然，这仅在磁头迁移之间没有冲突时才有效，在这种情况下，您将必须手动解决问题。
考虑到这里的一些人认为，你 不应该 提交你迁移到版本控制，我想为什么你实际上是扩大的原因 应该 这样做。
首先，您需要记录应用于生产系统的迁移。如果将更改部署到生产中并想迁移数据库，则需要描述当前状态。您可以为应用到每个生产数据库的迁移创建单独的备份，但这似乎不必要。
其次，迁移通常包含自定义的手写代码。并非总是可以使用自动生成它们
./manage.py makemigrations。
第三，迁移应包括在代码审查中。它们是对您的生产系统的重大更改，许多事情可能会出错。
简而言之，如果您关心生产数据，请检查您向版本控制的迁移。
