Managing conflict in schema.rb created by Git operation
I created a migration, ran
rake db:migrate, which bumped my db/schema.rb version number. Then I did a
git fetch origin master and saw that there were changes from my team members. So I did a
git stash and a
git rebase FETCH_HEAD, followed by a
git stash pop. This resulted in a conflict in db/schema.rb over the version number.
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.
- Capistrano Cold Start - problems with git:check
- Switching Heroku app to server in other region
- Specifying the same gem twice for development/test and production but different paths
- Capistrano Deploy not fetching latest commit from GitHub
- Ruby on Rails - Uncaught ReferenceError: $ is not defined
- How can I un-nest a Git repository
Is this sensible, or bad news?
7 Solutions collect form web for “Managing conflict in schema.rb created by Git operation”
If your current database has the correct schema, you should:
Run pending migrations (if any)
schema.rbfrom your current database schema
When I find myself with this conflict, I simply migrate the database. Whether there are pending migrations or not, the conflict will be corrected.
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.
Here’s what I do when merging master into my feature branch fails over conflicts in 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
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.
I feel the best approach is to do
rake db:drop db:create db:migrate to 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.
#!/usr/bin/env bash git co master bin/rake db:reset db:seed git co - bin/rake db:migrate