正在无序地合并ActiveRecord迁移

Question

假设我在Rails应用程序的git中工作，我有两个分支，每个分支都有自己的迁移。

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

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

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

但假设我先将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.