我的理解是,创建迁移的人也应该更新schema.rb
。由于我已经完成了迁移,因此我也应该已经完成了更新后的schema.rb
。但是,有时,schema.rb
在运行bundle exec rake db:migrate
之后会更新。
我当前的工作流程是:
git pull --rebase origin master --prune
rails s
路轨告诉我要迁移
bundle exec rake db:migrate
实现schema.rb
更新
目前,我很确定我不应该签入更新后的schema.rb
。我会通过git checkout origin/master db/schema.rb
手动将其还原。
那么在这种情况下出了什么问题?同事在创建迁移后是否忘记运行迁移?我做错什么了吗?
答案 0 :(得分:1)
据我所知,运行rails db:migrate后架构可能会由于以下原因而发生更改:
运行git diff将帮助您了解运行情况。
答案 1 :(得分:0)
schema.rb
保留两个关键数据集:
如果有新的开发人员加入您的团队,他们应该能够运行rake db:schema:load
并立即获得最新的数据库结构。这比期望它们手动完成所有迁移要有效和可靠。
运行rake db:migrate
,即使没有需要运行的未完成的迁移,也将始终重新生成db/schema.rb
。大多数情况下,您不会注意到,因为文件会相同–但是在空白格式或列顺序上可能会有所不同。
最佳实践(IMHO)应该始终是在与已添加的所有迁移相同的提交中检入更新的db/schema.rb
。
在获取或拉出分支到本地计算机时,运行rake db:migrate
将根据本地数据库schema_migrations
表中的记录应用需要运行的所有新迁移。此后,您的新db/schema.rb
应该与您下拉的那个相同–但是,如果不是,git diff
会告诉您有什么不同。
然后您可以判断最佳行动方案是什么。如果唯一的区别是外观,我个人倾向于还原未上演的更改,并保持提交的版本不变,直到下一次迁移。
如果通过在db/structure.sql
中指定config.active_record.schema_format = :sql
切换到基于SQL的结构文件(config/application.rb
),以上所有内容同样适用。