#ruby-on-rails #git #rails-migrations #git-flow
#ruby-on-rails #git #rails-миграции #git-flow
Вопрос:
Допустим, идет активная разработка как в моей основной ветке (devlop), так и в моей функциональной ветке. Оба добавляют миграции время от времени. Перед объединением ветви функций с основной ветвью я собираюсь перенести ее в основную ветвь.
Таким образом, имеет смысл выполнять все миграции ветвей функций только после самой последней миграции ветви разработки.
Есть ли удобный / рекомендуемый способ переименования этих файлов? Я могу просто сгенерировать фиктивные миграции и повторно использовать временные метки, сгенерированные для них — но мне интересно, есть ли лучшая / распространенная практика, о которой я не знаю?
Комментарии:
1. Просто вопрос: зачем вам это нужно делать? Rails все равно перенесет их все, независимо от временной метки. Не уверен насчет наилучшей практики, но текущая практика заключается в том, чтобы просто оставить их в покое и позволить им оставаться со своими временными метками как есть.
2. Вы правильно подметили. возможно, что одна из миграций в ветви функций может зависеть от миграции в develop, хотя это случается не часто, поскольку по определению она была написана до новой миграции в develop. так что, возможно, ответ заключается в использовании моего решения по переименованию, когда это явно необходимо.
3. Что часто случается, так это то, что люди выполняют обратное слияние из магистрали в функциональную ветвь, чтобы поддерживать ветвь в актуальном состоянии (чтобы избежать ужасных обратных слияний по завершении). Таким образом, вполне возможно, что функциональная ветвь будет зависеть от кода, разработанного в магистрали … только не наоборот.
Ответ №1:
Я не нашел функции rails, которая могла бы сделать это за вас, но было бы неплохо иметь migration touch команду или что-то в этомроде. В любом случае, что мы делаем в эти дни, это просто создаем новую миграцию, копируем временную метку и переименовываем старую. Как правило, миграции достаточно автономны, чтобы порядок не имел значения, но иногда мы сталкиваемся с зависимостями порядка, поэтому нам нужно обновить временные метки.
Комментарии:
1. Вот суть описанной вами сенсорной команды миграции. Он обновляет имя файла до последней версии, вызывает db:migrate:down для старой версии и db:migrate:up для новой версии.
Ответ №2:
Как упоминалось в комментариях к вашему вопросу, нет необходимости изменять имена файлов.
Также упоминалось, что обычно миграция не записывается в зависимости от другой миграции до того, как эта другая миграция будет создана. (Если это так, вы делаете что-то неправильно). Таким образом, необходимость не должна возникнуть.
В редком случае, когда разработчик функций захочет объединить несколько миграций (когда между миграциями функций есть промежуточная миграция), он должен объединить их в новую (или последнюю) миграцию. В любом случае, ответственность за соблюдение зависимостей лежит на разработчике функции.
Это также может создать некоторые раздражающие побочные эффекты для других разработчиков. Такая же миграция будет выполняться снова в их базе данных, поскольку временная метка в schema_migrations будет недоступна.
Комментарии:
1. Я думаю, что выражение «вы что-то делаете неправильно» является чрезмерно широким обобщением. У нас часто бывает случай, когда мы начинаем работу над одной миграцией, а затем понимаем, что есть обязательное изменение, поэтому мы должны сгенерировать другую и ввести ее до этой.
2. Не должно случиться так, что ветвь функций зависит от миграции в ветви разработчиков после точки, где они разошлись. Может случиться так, что в ветке функций вы захотите «добавить» миграцию — я согласен — но вопрос был не в этом.
3. Я не уверен, что понимаю, о чем вы говорите. Вот пример использования: Часто при написании ветви функций нам требуется миграция, которая добавляет столбец и заполняет его некоторыми данными из других полей и таблиц. Но в процессе мы понимаем, что исходные данные в некотором роде недействительны, поэтому мы создаем новую ветвь функций, чтобы очистить данные и добавить некоторые ограничения, объединить их, а затем вернуться к нашей исходной ветви функций и продолжить работу оттуда. Вы хотите сказать, что это неправильно?
4. В таком случае, да, это кажется правильным. Однако я надеюсь на вас, что это не обычная ситуация, когда ваши данные находятся в таком плохом состоянии, что вы не можете их обойти…
5. К лучшему это или к худшему, но многие кодовые базы заканчиваются именно так, поскольку люди не так хорошо осведомлены, когда начинают создавать приложение, как через два года. Я работал над множеством устаревших приложений, в которых данные необходимо переупорядочивать и ограничивать, чтобы двигаться вперед, включая некоторые из моих собственных. До сих пор нам всегда удавалось найти способ.