Ruby-on-rails 管理 Git 操作创建的 schema.rb 中的冲突

Managing conflict in schema.rb created by Git operation

提问by maxenglander

I created a migration, ran rake db:migrate, which bumped my db/schema.rb version number. Then I did a git fetch origin masterand saw that there were changes from my team members. So I did a git stashand a git rebase FETCH_HEAD, followed by a git stash pop. This resulted in a conflict in db/schema.rb over the version number.

我创建了一个迁移， run rake db:migrate，它增加了我的 db/schema.rb 版本号。然后我做了一个git fetch origin master，看到我的团队成员发生了变化。所以我做了 agit stash和 a git rebase FETCH_HEAD，然后是 a git stash pop。这导致 db/schema.rb 中的版本号冲突。

Upstream>>>
ActiveRecord::Schema.define(:version => 20110930179257) do
===========
ActiveRecord::Schema.define(:version => 20110930161932) do
<<<Stashed

I think the appropriate fix would be to manually increment the version number to something higher than the upstream.

我认为适当的解决方法是手动将版本号增加到高于上游的版本号。

Is this sensible, or bad news?

这是明智的，还是坏消息？

Thanks, Max

谢谢，马克斯

回答by Wizard of Ogz

If your current database has the correct schema, you should:

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

• Run pending migrations (if any)

  rake db:migrate
  

• Overwrite your schema.rbfrom your current database schema

  rake db:schema:dump
  

• And commit

• 运行挂起的迁移（如果有）

  rake db:migrate
  

• 覆盖您schema.rb当前的数据库架构

  rake db:schema:dump
  

• 并提交

回答by Sean M

When I find myself with this conflict, I simply migrate the database. Whether there are pending migrations or not, the conflict will be corrected.

当我发现自己遇到这种冲突时，我只需迁移数据库。无论是否有待处理的迁移，冲突都会得到纠正。

回答by lulalala

According to this answer, a conflict is guaranteed. The user has to to manually merge, and set the version as the higher of the two.

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

回答by Adam Sibik

tldr

域名

Accept the Upstream version and run rake db:migrateas you'd normally do.

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

why is that the way to go

为什么这是要走的路

Don't worry about the migrations you've created (which are below Upstream version 20110930179257). ActiveRecord uses a table schema_migrationswhere it puts all of the migrations that have been run. If your migrations aren't on the list but in db/migratedirectory, then ActiveRecord will run them.

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

Here's the table so you can visualise it better:

这是表格，以便您可以更好地对其进行可视化：

It's tempting to think that it's actually this line: ActiveRecord::Schema.define(:version => 20110930179257)that defines latest migration run, so no migrations with version below it are going to be run. This is fortunately not true. Rails will run any migrations that are in db/migratefolder and not yet in the schema_migrationstable.

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

回答by Mark Kreyman

Here's what I do when merging master into my feature branch fails over conflicts in db/schema.rb:

以下是我在将 master 合并到我的功能分支时执行的操作，以解决 db/schema.rb 中的冲突：

$ git merge --abort
$ git checkout master
$ rake db:drop db:create db:migrate
$ git checkout -- db/schema.rb
$ git checkout my_feature_branch
$ rake db:migrate
$ git add db/schema.rb
$ git commit -m 'Updated schema'
$ git merge master

回答by Dorian

~/bin/update-schema-rb:

~/bin/update-schema-rb：

#!/usr/bin/env bash

git co master
bin/rake db:reset db:seed
git co -
bin/rake db:migrate

回答by Dr.Strangelove

I feel the best approach is to do rake db:drop db:create db:migrateto regenerate schema using migrations that exist only on the current branch. That way migrations from other branches won't leak into your schema file and give you headache later - in case if you switch branches a lot.

我觉得最好的方法是rake db:drop db:create db:migrate使用仅存在于当前分支上的迁移来重新生成模式。这样，从其他分支的迁移就不会泄漏到您的架构文件中，并在以后让您头疼——以防您频繁切换分支。

回答by Adam Dymitruk

An option is to have a manual version script which is additive only. There you want conflicts. Schema is something that will bite you hard if you don't keep on top of it. So once bitten, twice shy, I don't mind keeping schema and lookup info (list of customer types) with an additive only change management scheme.

一种选择是使用手动版本脚本，该脚本仅可添加。你想要冲突。如果你不掌握它，Schema 就会让你很难受。因此，一旦被咬，两次害羞，我不介意将架构和查找信息（客户类型列表）与仅添加的更改管理方案保持一致。