Ruby on rails 无序合并ActiveRecord迁移

假设我在我的

Rails

应用程序的

git

中工作，我有两个分支，每个分支都有自己的迁移

1）

branch001

通过迁移创建名为

tableA

的表

20160101000000\u create\u table\u a

2）

branch002

通过迁移创建名为

tableB

的表

20160101000001\u create\u table\u B

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

但假设我首先将

branch002

合并到

master

，因为它首先准备好了。我的模式文件变为-

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

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

当我最终着手合并我的第一个分支时会发生什么

架构版本是否会回归到

20160101000000

运行第一个分支的迁移是否会有任何问题，因为模式看到它已经“修补”并跳过它

一般来说，对于这样的事情，最好的做法是什么？我应该用一个新的、最近的时间戳重命名第一个分支吗

谢谢

编辑-

真想知道当我将第二个分支合并到

master

中时，应该如何解决合并冲突。我应该将其保留为后面的时间戳还是将其回归到前面的时间戳

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

>282cda7。。。添加表B

如果发生冲突，您应该从两个选项中选择较大的一个。但无论您选择什么，它对实际迁移都没有影响

如果您选择较低的数字，那么下次运行

rake db:migrate

时，它将更改此数字（为较高的数字），并且您的

schema.rb中将有一个更改，并且不会进行迁移。这不是一个问题-只是你的提交会有点奇怪

Rails rake任务运行它找到的并且在
schema\u migrations
表中没有值的所有迁移。然后它获取最高的迁移时间戳，并将该时间戳放入
schema.rb
。整个迁移思想不是基于某个“最近的时间戳”（模式版本），而是基于
schema\u migrations
表的内容，该表包含它已经运行的所有迁移时间戳。因此，通过这个表，它保证不会跳过任何迁移。
非常简短的版本是，事情通常都很好：假设迁移不会相互干扰（例如一个删除了一个表，但另一个假设它仍然存在），您不应该遇到麻烦

虽然您的架构文件中只有一个版本号，但在运行迁移时，rails会将迁移文件列表与
schema\u migrations
表的内容进行比较，并运行所有尚未运行的迁移，即使最近已经运行了迁移

至于模式冲突，我个人只会运行迁移，这将重新生成schema.rb