49

Should we include schema.rb while commiting to GIT? or should we ignore it? what is the right approach?

rubyprince
  • 17,559
  • 11
  • 64
  • 104
  • 1
    possible duplicate of [What is the preferred way to manage schema.rb in git?](http://stackoverflow.com/questions/737854/what-is-the-preferred-way-to-manage-schema-rb-in-git) – Marc-André Lafortune Apr 06 '12 at 21:37

4 Answers4

69

Well the standard schema.rb file for Rails 2 has this at the end of the comment block at the top of the file:

# It's strongly recommended to check this file into your version control system.

The Rails 3 schema.rb that I have kicking around says the same thing. I think the comment says it all.

Update in response to comments: Yes, mistakes can be made and you can get conflicting changes and bugs mangling your schema.rb but that's why you want it under revision control, revision control allows you to keep track of everything and backup when needed. There is only one thing in your entire source tree that specifies your database schema and that is schema.rb. Your database schema absolutely is a critical artifact and anything that important needs to be tracked in revision control.

Any update/merge problems with schema.rb should be sorted out just by sorting out your conflicting migrations so schema.rb will get fixed as a side effect of fixing the real problem.

Yes, schema.rb is a generated file but it is only generated in the sense that your text editor generates your pancake.rb model file or an unedited scaffold file is generated.

Yes, you could rebuild your schema.rb file by building a new database and then running all of your migrations. But, you should clear out your old migrations now and then to avoid having to check hundreds of migration files every time you rake db:migrate so "rebuild and run all the migrations" often isn't an option in a highly active project.

mu is too short
  • 426,620
  • 70
  • 833
  • 800
  • do you commit the changes in this file to git, for example, after running a new migration? – rubyprince Jun 23 '11 at 09:35
  • @mu..@pcg79...I used to commit schema.rb initially into the GIT and then do not commit to the GIT,the changes made afterward.If anyone commit by mistake,will result in error while pulling.Then will have to checkout the file and pull.I am afraid this error will come when I commit the changes to the GIT.The problem is the schema.rb is overwrited each time a migration is executed.eg.the schema.rb from git have the schema updated but when we pull it,we will have to run `rake db:migrate` to make local db uptodate.This will update the `schema.rb` file and may result in error while pulling from git – rubyprince Jun 23 '11 at 16:13
  • @rubyprince, @pcg79: I added an update to address (at least that's the idea) some of the issues in the comments. – mu is too short Jun 23 '11 at 16:43
  • 1
    It seems like this would be appropriate to check into version control but not necessarily push around to your team members. "How?" you might ask. Branches my dear Watson, Branches. – Sean Dunford Mar 31 '13 at 00:36
  • 2
    Well, after starting commiting schema file to the GIT for multiple projects, right from the start of the project, I would say we have had only small minor conflicts, usually around the last migration number, which can be easily resolved. So, it had been a smooth ride overall. – rubyprince Oct 08 '15 at 11:39
  • 1
    @rubyprince: That's my experience as well, I've never had a conflict problem with `schema.rb` or `structure.sql` that wasn't solved by sorting out the migrations. – mu is too short Oct 09 '15 at 03:57
  • how about the migration files themselves? do you commit those as well? – ddavison Oct 28 '15 at 19:32
  • @sircapsalot: Yes, of course the migrations get committed. How else would changes get to other team members or the production systems? However, migrations get periodically deleted when they're no longer relevant and they start cluttering up the migrations directory. – mu is too short Oct 28 '15 at 19:56
  • sorry - it wasn't an "of course" for me. but yes, ok that makes sense. thanks – ddavison Oct 29 '15 at 00:24
  • 1
    @fatfrog Yes but "There is only one thing in your entire source tree that specifies your database schema and that is `schema.rb`". Sure you can try starting with an empty database and then running all the migrations but historic migrations can fail in all sorts of ways, the [official guide](https://guides.rubyonrails.org/active_record_migrations.html#what-are-schema-files-for-questionmark) even says so. `schema.rb` (or `structure.sql`) is the only accurate representation of your database schema, not tracking it is a mistake. – mu is too short Mar 19 '21 at 21:35
2

Yes. The schema file is used to configure your database when using rake db:reset and other commands. Migrations should only be used when changing the database schema and will always result in a new schema file.

askegg
  • 664
  • 6
  • 11
0

Well, it's not included on .gitignore by default. So, I think that you would not have a problem including it(I do in my projects, without any problem).

AMIC MING
  • 6,306
  • 6
  • 46
  • 62
Spyros
  • 46,820
  • 25
  • 86
  • 129
  • I include it in initial commit but, do you commit the changes to your schema file to git, for example, after running a new migration? – rubyprince Jun 23 '11 at 06:52
  • just as a part of commiting my other changes. I would not pay any more attention on commiting migrations more frequently. – Spyros Jun 23 '11 at 06:55
0

I don't commit this file to Git, because it create when I launch rake db:migrate.

If I will commit this file to Git, I cannot pull new changes from server after each db:migrate.

AMIC MING
  • 6,306
  • 6
  • 46
  • 62
ceth
  • 44,198
  • 62
  • 180
  • 289
  • 4
    I think if your `schema.rb` doesn't match what is generated by your migrations then you have another problem that you are ignoring by not committing `schema.rb` – James McMahon Feb 03 '14 at 16:27
  • I am agree with include `schema.r` to git but what I have to do when run in `development` enviroment `rake db:migrate` and then also in `production` enviroment??? – inye Sep 03 '15 at 15:23
  • 2
    @inye: You `rake db:migrate` in production, that will compare the `schema_migrations` table to your `db/migrate` directory to see what needs to be run to bring your production database up to date. – mu is too short Oct 08 '15 at 17:34