使用 South、Django 和 Git 时处理数据库迁移的正确方法是什么？答案

【问题标题】：What is the correct way to deal with DB migration while using South, Django and Git?使用 South、Django 和 Git 时处理数据库迁移的正确方法是什么？
【发布时间】：2012-04-10 04:30:43
【问题描述】：

背景：-

我正在使用 Django 1.3。我们使用 South 作为数据库迁移和 Git SCM 的模块。

问题：-

处理形成的迁移文件夹的正确方法是什么？

主要问题是我在开发机器中对数据库架构进行了更改，当我将其上传到生产服务器时，我必须迁移现有架构。这样做时，迁移文件总是存在一些问题。

我应该只将迁移文件夹添加到 gitignore 吗？还是有更好的方法？

【问题讨论】：

迁移文件有什么问题？我通常将这些检查到 git 中，只要您小心地将它们按顺序排列，它就可以正常工作（所以不要在不同的分支上并行创建新的）。
问题是，如果我在本地机器上迁移模式并尝试在生产机器上做同样的事情，它就可以工作一次。这行得通吗？即相同的迁移文件是否也适用于生产服务器？
是的，他们应该这样做，假设您没有对数据库进行其他更改。如果您有特定的错误消息或其他内容，我们可以尝试对其进行调试，但是“一次都没有工作”很难解决。 :p
@AkashDeshpande，是的，他们只需要处于相同的状态。这是南的主要目的（对我而言）——我可以在开发时重置我的所有表格，但在生产时则不行。当两个系统相等时，运行初始迁移（schemamigration --initial），提交它，然后在您的生产环境中migrate myapp 0001 --fake。从现在开始，您在本地创建的每个迁移都可以提交并安全地应用到服务器上。

标签： django git django-models database-migration django-south

【解决方案1】：

您应该将迁移文件夹添加到您的版本控制系统，并将相同的文件用于生产和开发。如果您不是从一开始就引入了迁移并且您已经拥有现有的表，那么您可能会在生产系统上遇到一些问题。

因此，您必须伪造第一次迁移，这通常与syncdb 在您第一次创建数据库时所做的相同。因此，当您第一次尝试在生产机器上为您的应用应用迁移时，请执行manage.py migrate app_name 0001 --fake。这让 South 知道，第一次迁移已经被应用（已经发生在 syncdb 中），当您再次运行 migrate 时，它将继续执行以下迁移。

【讨论】：

这正是我想要的。 :P 谢谢！！（找到您的答案并对其进行了研究。他们同意非常棒）