Подтвердить что ты не робот

Это хорошая идея поместить db/schema.rb в список .gitignore?

так что я предлагаю в своей работе, заключается в том, чтобы поместить файл db/schema.rb в файл .gitignore, поэтому у нас нет проблем времени для слияния.

Есть некоторые опасения, что если произойдет что-то ужасное (метеорит падает с неба прямо на сервер БД, а одновременно все файлы db/migrete повреждены), мы могли бы потерять схему, и нам придется использовать rake db: purge (для повторного использования schema.rb). Я согласен, что это возможно, и это хороший аргумент, но это не должно быть проблемой, потому что db/schema.rb генерируется каждый раз, когда мы делаем rake db: migrate. Таким образом, даже если мы не будем нажимать schema.rb на сервере, мы нажимаем на миграции, добавляем исполняемый db: каждый раз при развертывании с изменениями БД мы выполняем миграцию и с этим db: migrate rails автоматически генерирует schema.rb на стороне сервера, и это schema.rb находится на сервере без изменений, пока мы не выполним другой db: migrate.

Итак, каково ваше мнение, следует ли нам или не ставить db/schema.rb в git игнорировать?

Благодарю вас

4b9b3361

Ответ 1

Я всегда предлагаю сохранить schema.rb в версии contol, так как такие задачи, как rake db: schema: load зависят от того, что он есть.

О конфликтах, вы говорите о конфликтах версий схемы? Они легко смягчаются с использованием алгоритма слияния, показанного здесь: http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

Другие конфликты, такие как местоположение переключения столбцов, можно легко избежать, если вы будете осторожны с тем, что вы совершаете в репозитории.

Ответ 2

Вы должны поместить в VCS все, что вам нужно, чтобы воспроизвести операционную среду.
Если для восстановления вашего приложения вам нужно иметь право schema.rb (в правильной версии), то да, он может быть версией.

Но если вы можете получить его обратно через другой процесс, тогда он лучше подкрепляется каким-либо другим ссылочным, чем VCS.

Ответ 3

Когда вы переключаетесь между ветвями функций, которые разрабатывают разные атрибуты модели, то без schema.rb вам иногда нужно:

  • rake db:migrate:down VERSION=xxx миграции, которые были созданы некоторое время назад, но не объединены с другими ветвями.
  • git checkout branch
  • rake db:migrate перенести все вновь созданные ветки

Я столкнулся с некоторыми проблемами с этим в предыдущих проектах, где schema.rb находился в .gitignore. Каждый раз, когда я вижу, что что-то было не так, мне приходилось отбрасывать базу данных и воссоздавать миграцию, а с schema.rb я мог просто загрузить схему в доли секунды, а затем rake db:seed для загрузки данных. Но это не было критическим.

Мне также любопытно, какие у вас проблемы с слиянием schema.rb? В большинстве случаев вы можете переопределить этот файл, не беспокоясь об изменениях (я предполагаю, что вы не изменили структуру базы данных вручную) с помощью rake db:dump и просто добавьте ее как разрешение слияния.