web-dev-qa-db-ja.com

db /schema.rbを.gitignoreリストに入れるのは良い考えですか??

したがって、私の仕事で提案しているのは、db/schema.rbを.gitignoreファイルに入れることです。これにより、（時々）マージの問題が発生しなくなります。

何かひどいことが起こった場合（隕石がDBサーバー上で空から落下し、同時にすべてのdb/migreteファイルが破損した場合）、スキーマが失われる可能性があり、rake db：purgeを使用する必要があります（再利用するには） schema.rb）。これは可能であり、良い議論であることに同意しますが、db：migrateをrakeするたびにdb/schema.rbが生成されるため、問題はないはずです。したがって、サーバーにschema.rbをプッシュしない場合でも、DBの変更を使用してデプロイするたびに、実行中のdb：migrateを追加して移行をプッシュします。db：migrate Railsは自動的に生成されます）サーバー側のschema.rbであり、そのschema.rbは、別のdb：migrateを実行するまで変更されずにサーバー上にあります。

では、db/schema.rbをgitignoreに入れるべきか、入れないべきか、あなたの意見はどうですか？

ありがとうございました

ruby-on-railsgitmigrationgitignore
23
equivalent8

Rake db：schema：loadのようなタスクはそこにあることに依存するので、私は常にschema.rbをバージョンコントロールに保持することをお勧めします。

競合について、スキーマバージョンの競合について話しているのですか？これらは、ここに示すマージアルゴリズムを使用して簡単に軽減できます： http://tbaggery.com/2010/10/24/reduce-your-Rails-schema-conflicts.html

列定義の切り替え場所などの他の競合は、リポジトリにコミットする内容に注意することで簡単に回避できます。

32
Martijn

運用環境を再現するために必要なものは何でもVCSに入れる必要があります。
アプリケーションを再構築するために、適切なschema.rb（適切なバージョン）が必要な場合は、はい、バージョン管理できます。

ただし、別のプロセスで元に戻すことができる場合は、VCS以外の参照を介してバックアップすることをお勧めします。

4
VonC

異なるモデル属性のセットを開発する機能ブランチを切り替える場合、schema.rbがないと、次のことが必要になる場合があります。

  1. rake db:migrate:down VERSION=xxxしばらく前に作成されたが、他のブランチにマージされていない移行
  2. git checkout branch
  3. rake db:migrate新しく作成されたすべてのブランチを移行します

Schema.rbが.gitignoreにあった以前のプロジェクトで、これに関していくつかの問題が発生しました。何かがおかしいと思うたびに、データベースを削除して移行から再作成する必要がありましたが、schema.rbを使用すると、スキーマをほんの一瞬でロードしてから、rake db:seedでデータをロードできました。しかし、それは重要ではありませんでした。

また、schema.rbのマージでどのような問題が発生するのか知りたいですか？ほとんどの場合、rake db:dumpを使用して、変更（データベース構造を手動で変更していないと思います）を気にせずにこのファイルをオーバーライドし、マージ解決として追加することができます。

4
MBO