Каков предпочтительный способ управления 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.