ruby-on-rails - 乱序 merge ActiveRecord 迁移

Question

假设我在 git 工作在我的 Rails app，我有两个分支，每个分支都有自己的迁移。

1) branch001创建一个名为 tableA 的表通过迁移 20160101000000_create_table_A

2) branch002创建一个名为 tableB 的表通过迁移 20160101000001_create_table_B

很明显，第二次迁移的时间戳是在第一次迁移之后创建的。

但是假设我 merge 了branch002至 master首先，因为它先准备好了。我的架构文件变为 -

ActiveRecord::Schema.define(version: 20160101000001) do
  ....
end

架构版本告诉 activerecord 它已经修补到比我的第一个分支更高的级别/版本。

当我终于开始 merge 我的第一个分支时会发生什么？

1. 架构版本会退回到20160101000000吗？ ？
2. 运行第一个分支的迁移是否会出现任何问题，因为模式认为它已经“修补”并跳过它？
3. 一般来说，处理此类事情的最佳做法是什么？我是否应该使用更新的新时间戳重命名第一个分支？

谢谢!

编辑 -

真的想知道当我将第二个分支 merge 到 master 时我应该如何解决 merge 冲突.我应该将它保留为较晚的时间戳还是将其回归到较早的时间戳？

<<<<<<< HEAD (master)
ActiveRecord::Schema.define(version: 20160101000001) do
=======
ActiveRecord::Schema.define(version: 20160101000000) do
>>>>>>> 282cda7... Adding Table B

Answer 1

如果发生冲突，您应该选择两者中较大的数字。但无论您选择什么，它都不会影响实际迁移。

如果您选择较小的数字，那么下次您运行 rake db:migrate 时，它会更改此数字(变为较大的数字)并且您的 schema.rb 也会发生变化 并且没有迁移。这不是问题 - 只是您的提交会有点奇怪。

Rails rake 任务运行它找到的所有迁移，并且在 schema_migrations 表中没有值。然后它获取最高的迁移时间戳并将此时间戳放入 schema.rb。整个迁移想法不是基于某些“最近的时间戳”(架构版本)，而是基于 schema_migrations 表的内容，该表包含它已经运行的所有迁移时间戳。因此，通过此表可以保证不会跳过任何迁移。