如何使用South和Git同步多台机器？

Question

因此，虽然我喜欢South，但我一直遇到这个特定工作流程的问题：

• 在机器A上多次迁移
• 定期将更改推送到Git
• 经过长时间后，返回机器B
• 从Git拉取并且对于机器B来说，迁移会抛出各种错误。

这些错误通常是“表已存在”的错误。

现在，我已经阅读了许多博客文章和堆栈问题，老实说，并没有清晰的答案可以告诉我如何正确检查迁移文件（是否应该检查），以及如何真正将South与Git集成。

我想要的是如何详细地介绍如何正确地使用Git和South，并展示两台计算机之间的工作流程。

目前，我必须完全清除迁移文件夹并从头开始。这似乎不是一个好的处理方式。

- Sebastian

Answer 1

问题

当两个人创建迁移而没有相互同步时，南方和团队工作流程出现问题。

假设我们有一个仓库。A和B两个人克隆它，然后更改一些模型，创建迁移，然后将所有内容推回。我们将在仓库中拥有两个具有相同编号的迁移。

如果您尝试使用这样的历史记录进行迁移，南方将会抱怨。

Inconsistent migration history
The following options are available:
   --merge: will just attempt the migration ignoring any potential dependency conflicts.

如http://south.readthedocs.org/en/latest/tutorial/part5.html中所述，您可以尝试使用--merge选项，South将尝试合并迁移。如果有冲突的迁移更改了相同的模型，则此操作将失败。

./manage.py schemamigration --auto --merge appname 

团队的主要规则是：一次只有一个开发者可以更改一个模型。如果有人开始更改模型，则在他们的迁移文件最新之前，其他人不应该触碰它。

使用south和多个git分支的团队工作流规则：

1. 在更改模型之前，请仔细检查是否已经有人在更改
2. 尽快通知其他成员您的更改
3. 尽快同步您的迁移目录

此外，根据south文档： 当您拉取其他人的带有自己迁移的模型更改时，您需要创建一个新的空迁移，其中包含来自开发的两个分支的更改（如果您使用mercurial，则相当于合并提交）。要执行此操作，请运行：

 ./manage.py schemamigration --empty appname merge_models

merge_models 只有新的迁移名称

使用south和单一git分支的团队工作规则：

如果您的所有团队成员都提交到单一分支，则最佳策略是先进行模型更改，制作迁移并尽快推送。然后再进行其他代码的工作。

这些文章也可能会对您感兴趣：

http://andrewingram.net/2012/dec/common-pitfalls-django-south/ http://anthony-tresontani.github.io/Django/2013/03/15/south-workflow/

- Serafim Suhenky

Answer 2

我很想知道关于提交南部迁移文件的疑虑是从哪里产生的。我当然不知道有任何建议你不会这样做。

在您的工作流程中，您没有指定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多个迁移文件，并没有遇到您所描述的任何问题。

- Andrew Wilkinson

---

我在最初将South引入我的项目时，遇到了相同的问题“表已经存在”。即使从repo中拉取了所有迁移和其他内容。当我运行“migrate <app>”时，South提示我删除属于受管理模型的数据库。 - Marvin Dickhaus