Управление конфликтами в schema.rb, созданном операцией Git

Question

Я создал миграцию, запустил rake db:migrate, которая повысила мой номер версии db / schema.rb.Затем я сделал git fetch origin master и увидел, что произошли изменения от членов моей команды.Итак, я сделал git stash и git rebase FETCH_HEAD, а затем git stash pop.Это привело к конфликту в db / schema.rb из-за номера версии.

Upstream>>>
ActiveRecord::Schema.define(:version => 20110930179257) do
===========
ActiveRecord::Schema.define(:version => 20110930161932) do
<<<Stashed

Я думаю, что правильным решением было бы вручную увеличить номер версии до значения выше, чем для исходной версии.

Это разумная или плохая новость?

СпасибоМакс

Answer 1

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

• Запуск отложенных миграций (если есть)

  rake db:migrate
  

• Перезаписать schema.rb из вашей текущей схемы базы данных

  rake db:schema:dump
  

• И совершить

Answer 2

Когда я сталкиваюсь с этим конфликтом, я просто перемещаю базу данных.Независимо от того, ожидают миграции или нет, конфликт будет исправлен.

Answer 3

Согласно этому ответу конфликт гарантирован. Пользователь должен вручную объединить и установить версию как более высокую из двух.

Answer 4

Вот что я делаю, когда происходит слияние master в моей ветви функций из-за конфликтов в db / schema.rb:

$ git merge --abort
$ git checkout master
$ rake db:drop db:create db:migrate
$ git checkout -- db/schema.rb
$ git checkout my_feature_branch
$ rake db:migrate
$ git add db/schema.rb
$ git commit -m 'Updated schema'
$ git merge master

Answer 5

tldr

Примите версию Upstream и запустите rake db:migrate, как обычно.

почему это путь

Не беспокойтесь осозданные вами миграции (ниже версии Upstream 20110930179257).ActiveRecord использует таблицу schema_migrations, в которую помещаются все выполненные миграции.Если ваши миграции находятся не в списке, а в каталоге db/migrate, ActiveRecord запустит их.

Вот таблица, чтобы вы могли лучше ее визуализировать:

Заманчиво подумать, что на самом деле именно эта строка: ActiveRecord::Schema.define(:version => 20110930179257) определяет последний запуск миграциипоэтому никакие миграции с версией ниже не будут запущены.К счастью, это не так.Rails будет запускать любые миграции, которые находятся в папке db/migrate и еще не в таблице schema_migrations.

Answer 6

~/bin/update-schema-rb:

#!/usr/bin/env bash

git co master
bin/rake db:reset db:seed
git co -
bin/rake db:migrate

Answer 7

Мне кажется, что лучше всего сделать rake db:drop db:create db:migrate для регенерации схемы с использованием миграций, которые существуют только в текущей ветви.Таким образом, миграции из других веток не попадут в ваш файл схемы и не вызовут у вас головной боли позже - в случае, если вы часто переключаете ветви.

Answer 8

Возможность иметь скрипт ручной версии, который является только аддитивным.Там вы хотите конфликты.Схема - это то, что тебя сильно укусит, если ты не будешь держаться за нее.Так что, будучи укушенным, дважды застенчивым, я не возражаю, чтобы сохранить схему и информацию о поиске (список типов клиентов) с помощью только аддитивной схемы управления изменениями.