Menu
The general consensus is that when migrating you should check schema.rb into version control.
What is the right approach to deal with Rails db/schema.rb file in GIT?
My question is this- if my senior dev creates a migration & checks schema.rb, I pull the repo down and migrate on my end and it shows schema.rb has been changed- do I also commit my version of schema.rb and check that into version control as well?
946
asked Apr 11 '14 16:04
You are doing only a big mistake that you can correct quickly: you should really commit the file db/schema. rb in your repository. This is standard for rails application.
The schema. rb serves mainly two purposes: It documents the final current state of the database schema. Often, especially when you have more than a couple of migrations, it's hard to deduce the schema just from the migrations alone. With a present schema.
ruby-on-rails. git.
rb file is the place where you can populate your database with some sample records. So after doing a rake db:reset, the database will contain all the records you created in the seeds. rb file. However there are two problems with the default setup.
In theory, your schema.rb should be identical to the one that Senior Dev has committed, after you do the migration. If it isn't, then one of two things have happened:
schema.rb
schema.rb in a consistent way (there are many creative uses of migrations that might lead to this, let alone bugs).You should double check that Senior Dev has, in fact, committed schema.rb after they ran the migration. If they have, you should throw away the changes on your version of schema.rb in favour of theirs. If they have NOT, then you should commit your version of schema.rb, effectively correcting their mistake.
123
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
