Каков предпочтительный способ управления schema.rb в git?

Question

Я не хочу добавлять schema.rb к .gitignore, потому что я хочу иметь возможность загрузить новую схему базы данных из этого файла. Тем не менее, его регистрация вызывает всевозможные ложные конфликты, которые легко разрешаются новым db:migrate:reset.

В основном я хочу способ:

2. Храните schema.rb в репозитории для настройки базы данных времени развертывания
3. Храните schema.rb в '.gitignore' для общего развития

Один или два человека будут отвечать за обновление schema.rb и знать, что это правильно.

Есть ли способ, которым я могу взять свой пирог и съесть его тоже?

Answer 1

Боюсь, что волшебного решения, которое вы ищете, не существует. Этот файл обычно управляется в управлении версиями, затем для любых конфликтов в строке версии просто выберите более позднюю из двух дат. Пока вы также выполняете все связанные миграции, ничто не должно синхронизироваться таким образом. Если два разработчика вызвали изменения в аналогичной области schema.rb и у вас возникают конфликты в дополнение к версии, то вы сталкиваетесь с обычным разрешением конфликтов слиянием, но, на мой взгляд, их обычно легко понять и разрешить. Я надеюсь, что это поможет некоторым!

Answer 2

Еще одна вещь, которую вы можете сделать, это использовать:

git update-index --assume-unchanged /path/schema.rb

Это сохранит файл в хранилище, но не будет отслеживать изменения. Вы можете переключить отслеживание в любое время, используя:

git update-index --no-assume-unchanged /path/schema.rb

Answer 3

Что действительно хорошо для меня сработало, так это удалить и .gitignore schema.rb, а затем восстановить его для каждого разработчика, когда они rake db:migrate.

Вы все еще можете достичь того, что хотели, не переходя с нуля и не рискуя прервать миграцию много лет назад, просто периодически «свернув» миграцию. Вы можете сделать это:

1. Запустите все ожидающие миграции с помощью rake db:migrate
2. Получение содержимого вашего schema.rb в блоке ActiveRecord::Schema.define
3. Вставьте его в вашу миграцию initial_schema внутри def up (перезаписывая то, что уже есть)
4. Удалить все другие миграции

Теперь ваша миграция initial_schema является отправной точкой для новых систем, и вам не нужно беспокоиться о конфликтах в schema.rb, которые могут быть не разрешены правильно. Это не волшебно, но работает.

Answer 4

Я построил драгоценный камень, чтобы решить эту проблему.

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

https://github.com/jakeonrails/fix-db-schema-conflicts

После добавления его в свой Gemfile вы просто запускаете rake db:migrate или rake db:schema:dump как обычно.

Answer 5

Вы можете определить стратегию слияния. Я нашел это решение, но не помню источник

[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"

Answer 6

Вместо использования .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 ветви - это указатели на коллекции содержимого файлов, поэтому они могут включать или исключать определенные файлы, а также отслеживать версии файлов. Это делает их гибкими инструментами для построения вашего конкретного рабочего процесса.

Answer 7

Было бы достаточно сделать rake db: dump в хите pre-commit git?

Следующее не обязательно исправит (1) или (2), но может решить проблему слияния, а затем, возможно, (1) и (2) исчезнет.

Answer 8

1. Зафиксировать schema.rb файл.
2. Запустите git pull (или продолжите то, что вы делаете)

Каждый раз, когда вы переносите базу данных, файл schema.rb обновляется и появляется в git status. Когда вы работаете над чем-то и иногда делаете git pull, это может раздражать, потому что вы должны зафиксировать файл schema.rb, прежде чем пытаться разрешить конфликт. Это означает, что каждый раз, когда вы переносите базу данных, вам нужно зафиксировать schema.rb файл.