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