Rails 迁移顺序和 Git

Question

由于使用 Rails + git 进行迁移是一种痛苦，所以新的刺已经出现了。

在我对我的产品数据库造成任何损害之前，以下情况会造成严重破坏吗？如果是这样，我该如何处理？

我正在一个单独的分支 ( ) 中开发一个长期功能feature/long-term。这个功能是对很多组件的大修，需要一段时间才能完成。此功能有新的迁移，已迁移到本地主机数据库。

同时，我需要通过另一个分支（）修复/添加到产品系统的迁移feature/quick-fix。其中有一个迁移文件，其日期晚于feature/long-term迁移。

quick-fixthe和 the的迁移long-term彼此无关，它们不会冲突并且在不同的表上工作。它们的运行顺序并不重要。

如果我合并feature/quick-fix到 master 并db:migrate在几天/几周内合并feature/long-term迁移文件顺序将是long-term第一个。

这会以某种方式影响数据库吗？（产品数据库很重要，所以我不想reset）

Answer 1

您所描述的是一个非常常见的开发工作流程（尤其是在拥有更多成员的团队中），并且它对于您的生产数据库来说是完全安全的。

\n

从版本 2.1 开始，Rails 足够智能，可以保留曾经运行的所有迁移的列表，而不仅仅是运行的最新迁移版本。该信息存储在一个名为 的单独表中schema_migrations。

\n

因此，如果您今天推送一个新的迁移，20140527_quick_fix.rb一个月后您推送一个新的（但时间戳较旧）迁移20140101_long_term_feature.rb，Rails 仍然会知道后者从未在您的生产环境中运行，因此在过程中rake db:migrate它将处理它，如您所料。当然，最新的不会再次运行，因为 Rails 会知道它已经被处理过。

\n

来自官方文档：

\n

\n

Rails 2.0 及更早版本用于在使用迁移时创建名为 schema_info 的表。该表包含截至上次应用的迁移时的架构版本。

\n

从 Rails 2.1 开始，schema_info 表（自动）被 schema_migrations 表替换，其中包含所有应用的迁移的版本号。

\n

因此，现在可以添加编号低于当前架构版本的迁移文件：向上迁移时，将自动应用那些从未应用的 \xe2\x80\x9cinterleaved\xe2\x80\x9d 迁移，而当向下迁移时，从未应用的 \xe2\x80\x9cinterleaved\xe2\x80\x9d 迁移将被跳过。

\n

\n