ruby-on-rails - Rails 迁移顺序和 Git

Question

由于使用 rails + git 进行迁移是一种痛苦，新的荆棘如雨后春笋般涌现..

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

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

与此同时，我需要通过另一个分支 (feature/quick-fix) 修复/添加到 prod 系统的迁移。这有一个迁移文件，其日期晚于 feature/long-term 迁移。

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

如果我将 feature/quick-fix merge 到 master 和 db:migrate 并在几天/几周内 merge feature/long-term 迁移文件顺序将是 long-term 优先。

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

Answer 1

您所描述的是一个非常常见的开发工作流程(尤其是在成员较多的团队中)并且它对您的生产数据库来说是绝对安全的。

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

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

来自official documentation :

Rails versions 2.0 and prior used to create a table called schema_info when using migrations. This table contained the version of the schema as of the last applied migration.

Starting with Rails 2.1, the schema_info table is (automatically) replaced by the schema_migrations table, which contains the version numbers of all the migrations applied.

As a result, it is now possible to add migration files that are numbered lower than the current schema version: when migrating up, those never-applied “interleaved” migrations will be automatically applied, and when migrating down, never-applied “interleaved” migrations will be skipped.