views:

1059

answers:

3

I don't want to add schema.rb to .gitignore, because I want to be able to load a new database schema from that file. However, keeping it checked in is causing all sorts of spurious conflicts that are easily resolved by a fresh db:migrate:reset.

Basically I want a way to:

  1. Keep schema.rb in the repository for deploy-time database setup
  2. Keep schema.rb in '.gitignore' for general development

There would be one or two people responsible for updating schema.rb and knowing that it was correct.

Is there a way I can have my cake and eat it, too?

A: 

Would it be sufficient to do a rake db:dump in a pre-commit git hook?

The following won't necessarily fix (1) or (2), but it might take care of the merging issue, and then maybe (1) and (2) go away.

dbrown0708
+3  A: 

Hi Otto, I'm afraid the magic solution you're looking for does not exist. This file is normally managed in version control, then for any conflicts on the version line just choose the later of the two dates. As long as you're also running all of the associated migrations nothing should get out of sync this way. If two developers have caused modifications to a similar area of schema.rb and you get conflicts in addition to the version then you are faced with a normal merge conflict resolution, but in my opinion these are normally easy to understand and resolve. I hope this helps some!

Adam Alexander
`schema.rb` went in ignore. You're right, there's no magic solution. Anything depending on files sometimes ignored vs sometimes not had all kinds of issues. I hope this doesn't bite me later.
Otto
A: 

Instead of using .gitignore, use separate branches: Develop which omits schema.rb and Test and Deploy which include schema.rb. Only make code changes in the Develop branches and never merge from Test into Develop. Keep schema.rb in a separate branch:

Developer A             
    Develop      --------             
    Local Schema          \           Your Repo
    Test                    --------->    Dev A
                            --------->    Dev B
Developer B               /               Master
    Develop      --------                 Schema
    Local Schema                          Test
    Test                                  Deploy

In Git, branches are pointers to collections of file contents, so they can include or exclude particular files as well as track file versions. This makes them flexible tools for building your particular workflow.

Paul
Doesn't this mean that git merge develop from either test or deploy makes a merge commit vs. being able to always be a fast-forward?I like the idea, I'm just not 100% there with seeing how it works, yet.
Otto
Paul
IMHO the cure is worse than the disease here. I've tried git workflows where branches have different files in them, and it's never been worth the hassle. I'm sure there are cases where a heavy-handed approach like this is necessary, but managing schema.rb is not it.
dasil003