Каков предпочтительный способ управления schema.rb в git?
Я не хочу добавлять schema.rb
в .gitignore
, потому что хочу иметь возможность загружать новую схему базы данных из этого файла. Тем не менее, сохранение этого параметра вызывает всевозможные ложные конфликты, которые легко разрешаются свежим db:migrate:reset
.
В принципе, мне нужен способ:
- Храните файл schema.rb в репозитории для установки базы данных развертывания
- Сохранить schema.rb в '.gitignore' для общей разработки
Было бы один или два человека, ответственных за обновление schema.rb
и зная, что это правильно.
Есть ли способ, которым я могу иметь торт и съесть его тоже?
Ответы
Ответ 1
Для меня было очень полезно удалить и .gitignore schema.rb
, а затем обновить его для каждого разработчика, когда они rake db:migrate
.
Вы все еще можете достичь того, чего хотите, не переходя от 0 и рискуя сломанными миграциями с лет назад, просто периодически "свертывая" миграции. Вы можете сделать это:
- Запустите все выдающиеся миграции с помощью
rake db:migrate
- Взяв содержимое вашего
schema.rb
в блоке ActiveRecord::Schema.define
- Вставьте его в свою начальную миграцию внутри
def up
(перезаписывая то, что уже есть)
- Удалить все другие миграции
Теперь ваша миграция initial_schema является отправной точкой для новых систем, и вам не нужно беспокоиться о конфликтах в schema.rb
, которые могут быть неправильно решены. Это не волшебство, но оно работает.
Ответ 2
Я боюсь, что волшебного решения, которого вы ищете, не существует. Обычно этот файл управляется в управлении версиями, а затем для любых конфликтов в строке версии просто выберите более позднюю из двух дат. Пока вы также выполняете все связанные миграции, ничто не должно выходить из синхронизации таким образом. Если два разработчика вызвали модификации в аналогичной области schema.rb, и вы получаете конфликты в дополнение к версии, то вы столкнулись с нормальным разрешением разрешения слияния, но, на мой взгляд, их обычно легко понять и решить. Надеюсь, это поможет некоторым!
Ответ 3
Еще одна вещь, которую вы можете сделать, это использовать:
git update-index --assume-unchanged /path/schema.rb
Это сохранит файл в репозитории, но не будет отслеживать изменения. вы можете переключить отслеживание в любое время, используя:
git update-index --no-assume-unchanged /path/schema.rb
Ответ 4
Достаточно ли сделать рейк db: сброс в pre-commit git hook?
Следующее не обязательно будет исправлять (1) или (2), но оно может позаботиться о проблеме слияния, а затем, возможно, (1) и (2) уйти.
Ответ 5
Вместо использования .gitignore
используйте отдельные ветки: Develop
, который пропускает schema.rb
и Test
и Deploy
, которые включают schema.rb
. Делайте только изменения кода в ветвях разработки и никогда не сливайтесь с Test
в Develop
. Держите schema.rb
в отдельной ветке:
Developer A
Develop --------
Local Schema \ Your Repo
Test ---------> Dev A
---------> Dev B
Developer B / Master
Develop -------- Schema
Local Schema Test
Test Deploy
В Git ветки являются указателями на коллекции содержимого файла, поэтому они могут включать или исключать определенные файлы, а также версии файлов треков. Это делает их гибкими инструментами для создания вашего рабочего процесса.
Ответ 6
Вы можете определить стратегию слияния.
Я нашел это решение, но не помню источник
[merge "railsschema"]
name = newer Rails schema version
driver = "ruby -e '\n\
system %(git), %(merge-file), %(--marker-size=%L), %(%A), %(%O), %(%B)\n\
b = File.read(%(%A))\n\
b.sub!(/^<+ .*\\nActiveRecord::Schema\\.define.:version => (\\d+). do\\n=+\\nActiveRecord::Schema\\.define.:version => (\\d+). do\\n>+ .*/) do\n\
%(ActiveRecord::Schema.define(:version => #{[$1, $2].max}) do)\n\
end\n\
File.open(%(%A), %(w)) {|f| f.write(b)}\n\
exit 1 if b.include?(%(<)*%L)'"
поставьте это "где-то" и
git-config --global core.attributesfile "somewhere"
Ответ 7
Я создал камень для решения этой проблемы.
Он сортирует столбцы, имена индексов и внешние ключи, удаляет лишние пробелы и запускает Rubocop для некоторого форматирования, чтобы унифицировать вывод вашего файла schema.rb.
https://github.com/jakeonrails/fix-db-schema-conflicts
После добавления в Gemfile вы просто запускаете rake db:migrate
или rake db:schema:dump
как обычно.
Ответ 8
- Зафиксировать
schema.rb
файл.
- Запустите git pull (или продолжите то, что вы делаете)
Каждый раз, когда вы переносите базу данных, файл schema.rb
обновляется и появляется в git status
. Когда вы работаете над чем-то и иногда делаете git pull
, это может раздражать, потому что вы должны зафиксировать файл schema.rb
, прежде чем потянуть, чтобы разрешить конфликт. Это означает, что каждый раз, когда вы переносите базу данных, вам необходимо зафиксировать файл schema.rb
.