管理由Git操作创建的schema.rb中的冲突

max*_*der 52 migration git ruby-on-rails

我创建了一个迁移,运行rake db:migrate,这突破了我的db/schema.rb版本号.然后我做了一个git fetch origin master,看到我的团队成员发生了变化.所以我做了一个git stash和一个git rebase FETCH_HEAD,然后是一个git stash pop.这导致db/schema.rb与版本号冲突.

Upstream>>>
ActiveRecord::Schema.define(:version => 20110930179257) do
===========
ActiveRecord::Schema.define(:version => 20110930161932) do
<<<Stashed
Run Code Online (Sandbox Code Playgroud)

我认为适当的修复方法是手动将版本号增加到高于上游的值.

这是明智的还是坏消息?

谢谢,马克斯

Wiz*_*Ogz 87

如果您当前的数据库具有正确的架构,您应该:

  • 如果您有挂起的迁移,请运行它们,然后运行`rake db:schema:dump` (10认同)
  • 如果远程版本更高,这不会创建一个拉取请求而不更改 schema.rb 中的版本吗? (2认同)

Sea*_*lls 19

当我发现自己遇到这种冲突时,我只是迁移数据库.是否有未决的迁移,冲突将得到纠正.


Ada*_*bik 9

域名

接受上游版本并rake db:migrate像往常一样运行。

为什么这是要走的路

不要担心您创建的迁移(低于 Upstream version 20110930179257)。ActiveRecord 使用一个表schema_migrations来放置所有已运行的迁移。如果您的迁移不在列表中而是在db/migrate目录中,则 ActiveRecord 将运行它们。

这是表格,以便您可以更好地对其进行可视化: schema_migrations 表

很容易认为它实际上是这一行: ActiveRecord::Schema.define(:version => 20110930179257) 它定义了最新的迁移运行,因此不会运行低于它的版本的迁移。幸运的是,事实并非如此。Rails 将运行db/migrate文件夹中但尚未在schema_migrations表中的任何迁移。


lul*_*ala 7

根据这个答案,保证了冲突.用户必须手动合并,并将版本设置为两者中的较高者.