所以，虽然我喜欢 South，但我一直在这个特定的工作流程上遇到问题：
这些错误通常是“表已存在”错误。
现在我已经阅读了许多博客文章和堆栈问题，坦率地说，关于如何正确签入迁移文件（以及是否应该）以及如何真正集成似乎并没有一个明确的答案南方与 Git。
我正在寻找的是如何正确使用 Git 和 South 的详细介绍，并展示两台机器之间的工作流程。
目前，我必须做的是在一段时间后完全清除迁移文件夹并从头开始。这似乎不是处理事情的好方法。
【问题讨论】：
标签： python django git django-south
我很想知道在提交 South 迁移文件时出现了疑问。我当然不知道有任何建议你不会。
在您的工作流程中，您无需指定机器 A 和 B 使用相同还是不同的数据库。如果您的代码在两台机器之间存在显着差异，那么它们应该使用不同的数据库。如果数据库架构领先于代码，那么您将收到错误。显然，架构不能落后于代码，因为您应该始终在代码更新后运行migrate。
我的工作流程如下：
A: create schema migrations and apply as they are created.
A: add schema migration files to subversion and commit
B: svn up
B: python manage.py migrate
B: continue coding!
由于迁移文件可能包含转换数据库中数据的代码，因此您不应删除迁移，因为您将丢失该代码。我有一个三人开发团队，他们创建了 80 多个迁移，并且没有遇到您描述的形式的任何问题。
【讨论】：
table already exists。即使有迁移和从回购中提取的所有内容。当我运行 migrate <app> 时，South 提示我删除属于托管模型的数据库。
当两个人创建迁移但彼此不同步时，会出现南和团队工作流。
假设我们有一些回购。人员 A 和 B 克隆它，然后更改一些模型，创建迁移，然后将其全部推回。我们将在 repo 中进行 2 个具有相同编号的迁移。
如果你试图用这样的历史进行迁移，南方会抱怨。
Inconsistent migration history
The following options are available:
--merge: will just attempt the migration ignoring any potential dependency conflicts.
如 south docs http://south.readthedocs.org/en/latest/tutorial/part5.html 中所述，您可以尝试使用 --merge 选项，而 south 将尝试合并迁移。如果有冲突的迁移更改了相同的模型，它将失败。
./manage.py schemamigration --auto --merge appname
因此，团队的主要规则是：一次只有一名开发人员可以更改一种模型。如果有人开始更改模型，那么在他们更新迁移文件之前，任何人都不应触碰它。
也来自南文档： 当您通过自己的迁移完成其他人的模型更改时，您需要创建一个新的空迁移，其中冻结两个开发分支的更改（如果您使用过 mercurial，这相当于合并提交)。为此，只需运行：
./manage.py schemamigration --empty appname merge_models
merge_models 只有新的迁移名称
如果您的所有团队成员都致力于单个分支，那么最好的策略是先进行模型更改，然后进行迁移并尽快推送。然后处理其他代码。
这篇文章对你来说也可能很有趣：
http://andrewingram.net/2012/dec/common-pitfalls-django-south/ http://anthony-tresontani.github.io/Django/2013/03/15/south-workflow/
【讨论】：