无序地合并ActiveRecord迁移

Question

假设我正在git使用我的Rails应用程序,我有两个分支,每个分支都有自己的迁移.

1)branch001创建一个名为tableAvia migration 的表20160101000000_create_table_A

2)branch002创建一个名为tableBvia migration 的表20160101000001_create_table_B

显然,第二次迁移的时间戳是在第一次迁移之后创建的.

但是,让我说我首先合并branch002,master因为它已经准备好了.我的架构文件变成 -

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

模式版本告诉activerecord它已经修补到比我的第一个分支更大的级别/版本.

当我终于合并我的第一个分支时会发生什么？

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

谢谢!

编辑 -

真的想知道当我合并第二个分支时我应该怎么做才能解决合并冲突master.我应该将其作为较晚的时间戳保留还是将其退回到较早的时间戳？

<<<<<<< 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包含已经运行的所有迁移时间戳的表的内容.因此,通过此表可确保不会跳过任何迁移.

Answer 2

非常简短的版本是事情通常很好:假设迁移不会相互干扰(例如,一个删除一个表但另一个假设它仍然存在),你不应该遇到麻烦.

虽然您的模式文件中包含单个版本号,但当您运行迁移时,rails会将迁移文件列表与schema_migrations表的内容进行比较,并运行尚未运行的任何迁移,即使最近的迁移已经存在已经运行了.

至于架构冲突,我个人只会运行迁移,这将重新生成schema.rb.