为什么需要将django迁移到版本控制系统

这是一个常见的做法，django项目的工作人员通常会将迁移与其他代码一起推送到版本控制系统。为什么需要将django迁移到版本控制系统

我的问题是为什么这种做法如此普遍？为什么不推动更新的模型，每个人都在本地生成迁移。这种方法也可以减少解决迁移冲突的工作。

来源

2015-09-03 Ishtiaq

如果您没有将它们提交到VCS，那么会发生什么情况会导致人们对模型进行潜在的冲突更改。

当最终准备好部署时，您仍然需要django进行新的迁移，然后再将每个修改组合在一起。这只是创造了一个额外的不必要的步骤，可以引入错误。

您也假定每个人都将始终能够处理代码的最新版本，当您开始处理尚未准备好合并到主线的分支时，这并不总是可行。

来源

2015-09-03 12:58:00 Sayse

一个例子是：person A从'master'创建了一个分支并创建了一个新的迁移'0010'，B从'master'创建了一个分支并创建了一个新的迁移'0010'。一个合并开发早于B，当B拉最新的变化，并试图将他的代码合并到“主”，他得到了重复的迁移。如果你不跟踪迁移，B会很困惑。 –

OP建议推送模型文件，并从这些文件生成迁移，应该照顾到这一点。我自己也想过这个。解决不一致的迁移问题，尤其是对于共享分支机构和正在进行的工作，一直是时间的极大浪费。我在@Alasdair关于自动填充的下面看到了一点（这是对我来说很有意义的一个例外，但如果您使用工厂而不是自定义迁移，则不适用）。我希望看到有关避免移民冲突的最佳做法和/或更好的解决方法的更好建议。例如， – szeitlin

，我刚碰到一个我经常遇到的问题，当我尝试迁移时，合并依赖关系丢失。问题是，单独应用程序中的迁移文件并不总是跨分支同步。 django错误不会给你导致问题的迁移文件的完整路径，只有数字。 #fail – szeitlin

首先，版本控制中的迁移允许您在生产中运行它们。

其次，迁移并不总是自动生成。例如，如果您向模型添加新字段，则可以编写迁移来填充该字段。这种迁移不能从模型中重新创建。如果该迁移不在版本控制中，那么其他人将无法运行它。

来源

2015-09-03 12:50:47 Alasdair

但我们也可以在生产中生成迁移，然后应用这些迁移。这种方法有问题吗？ – Ishtiaq

是的，理论上你可以在生产中生成迁移（虽然不是自定义迁移，如上所述）。但是，如果您需要在更新代码之前运行迁移（例如添加新模型），则在生产中创建迁移可能会导致问题。 – Alasdair

@Alasdair谈论的是你应该跟踪他们，因为可能需要数据迁移（自定义迁移）。在某些情况下，人们手动编写迁移以实现类似填充初始数据等操作。如果您没有将它们保存在版本控制中，则会失去跟踪这些步骤的情况。 –

迁移将数据库的状态与代码的状态同步。如果您没有检入到版本控制的迁移，则会丢失中间步骤。您将无法返回版本控制历史记录并仅运行代码，因为数据库在该时间点不匹配模型。

像任何代码一样，迁移应该至少在基本级别上进行测试。即使它们是自动生成的，但这并不能保证它们能够百分之百地工作。因此，安全的途径是在您的开发环境中创建迁移，测试它们，然后将它们推送到生产环境以在那里应用它们。

来源

2015-09-03 12:55:53 knbk

你能举个例子说明你用什么样的测试吗？你检查数据人口？ – szeitlin

为什么需要将django迁移到版本控制系统

回答

相关问题