假设我在我的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它已经修补到比我的第一个分支更大的级别/版本.
当我终于合并我的第一个分支时会发生什么？
>架构版本会回归到20160101000000吗？
>运行第一个分支的迁移是否会出现任何问题,因为模式已经“修补”并跳过它？
>一般来说,这样的事情最好的做法是什么？我应该使用新的更新的时间戳重命名第一个分支吗？
谢谢！
编辑 –
真的想知道当我将第二个分支合并到master时我应该怎么做才能解决合并冲突.我应该将其作为后期时间戳保留还是将其退回到较早的时间戳？
<<<<<<< HEAD (master) ActiveRecord::Schema.define(version: 20160101000001) do ======= ActiveRecord::Schema.define(version: 20160101000000) do >>>>>>> 282cda7... Adding Table B
解决方法
如果发生冲突,您应该选择两者中较高的数字.但无论你选择什么,它对实际的迁移都没有影响.
如果选择较小的数字,那么下次运行rake db：migrate时,它将更改此数字(更高的数字),您将在schema.rb中进行更改而不进行迁移.这不是问题 – 只有你的提交会有点奇怪.
Rails rake任务运行它找到的所有迁移,并且在schema_migrations表中没有值.然后它需要最高的迁移时间戳并将此时间戳放入schema.rb中.整个迁移的想法不是基于某些“最新时间戳”(架构版本),而是基于schema_migrations表的内容,该表包含已经运行的所有迁移时间戳.因此,通过此表可确保不会跳过任何迁移.