Нужно ли добавлять файлы миграции в git

Обновлено: 05.07.2024

Должен ли я добавлять файлы миграции Django в файл .gitignore ?

Я недавно получал много проблем git из-за конфликтов миграции и задавался вопросом, следует ли отмечать файлы миграции как игнорировать.

Если да, то как я могу добавить все миграции, которые у меня есть в своих приложениях, и добавить их в файл .gitignore ?

ОТВЕТЫ

Ответ 1

Цитата из документации Django миграции:

Файлы миграции для каждого приложения находятся в каталоге "migrations" внутри этого приложения и предназначены для того, чтобы быть привязанным к его кодовой базе и распределенным как часть ее. Вы должны сделать их один раз на своей машине разработки, а затем выполнить те же самые миграции на компьютерах ваших коллег, на ваших станционных машинах и, в конечном итоге, на своих производственных машинах.

Если вы следуете этому процессу, вы не должны получать конфликты слияния в файлах миграции.

Чтобы устранить любые проблемы, которые у вас есть, вы должны указать, какой репозиторий или ветвь имеет авторитарную версию файлов миграции, а затем использовать механизм атрибутов git для укажите стратегию слияния "наши" для этих файлов. Это означает, что git всегда игнорирует внешние изменения этих файлов и предпочитает локальную версию.

Ответ 2

Я занимаюсь этим много раз, и я не могу, в моей жизни, найти случай, когда нам нужны миграции в репо.

Как я вижу, окончательная запись схемы models.py . Если я сменю изменение, а кто-то его потянет, все будет правильно, когда они запустит makemigrations и migrate . Нет необходимости определять, какая стратегия "нашего" для миграции.

Если нам нужно откат, мы возвращаем models и переносимся. Все хорошо, никаких проблем, никогда.

Нет жалобы на то, что поле уже существует и т.д.

Интересно, может ли кто-нибудь дать мне конкретный случай, когда мне будет полезно объединить другие файлы миграции разработчиков, прежде чем я смогу приступить к работе. Я знаю, что документы говорят, что я должен, поэтому я так и предполагаю. Но я никогда не встречал даже одного.

Ответ 3

Вы можете выполнить описанный ниже процесс.

Вы можете запустить makemigrations локально, и это создаст файл миграции. Зафиксируйте этот новый файл миграции для репо.

По-моему, вы не должны запускать makemigrations в производстве вообще. Вы можете запустить migrate в процессе производства, и вы увидите, что миграция применяется из файла миграции, который вы проверили, из локального. Таким образом, вы можете избежать всех конфликтов.

Ответ 4

Похоже, вам нужно настроить рабочий процесс git, вместо того чтобы игнорировать конфликты.

В идеале каждая новая функция разрабатывается в другой ветке и объединяется с запросом pull.

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

Ответ 5

Я не могу представить, что почему у вас появятся конфликты, если вы каким-либо образом не редактируете миграцию? Обычно это заканчивается неудачно - если кто-то пропускает некоторые промежуточные коммиты, то они не будут обновляться с правильной версии, и их копия базы данных будет повреждена.

Процесс, который я выполняю, довольно прост - всякий раз, когда вы меняете модели для приложения, вы также совершаете перенос, а затем , что перенос не изменяется - если вам нужно что-то другое в затем измените модель и выполните новую миграцию вместе с изменениями.

В проектах с новыми проектами вы можете часто удалять миграцию и начинать с нуля с переносом 0001_ при выпуске, но если у вас есть производственный код, вы не можете (хотя вы можете скворовать миграции вниз на один).

Ответ 6

Обычно используемое решение состоит в том, что, прежде чем что-либо объединяется в master, разработчик должен вытащить любые удаленные изменения. Если есть конфликт в версиях миграции, он должен переименовать его локальную миграцию (удаленный был запущен другими разработчиками и, возможно, в процессе производства), до N + 1.

Во время разработки может быть хорошо, чтобы просто не совершать миграции (не добавляйте игнорирование, а просто не add их). Но как только вы перейдете к производству, вам понадобятся они, чтобы синхронизация схемы с изменениями модели.

Затем вам необходимо отредактировать файл и изменить dependencies на последнюю удаленную версию.

Это работает для переноса Django, а также других подобных приложений (sqlalchemy + alembic, RoR и т.д.).

Поделитесь опытом, нужно ли вносить файлы миграции под систему контроля версий? Их же можно самостоятельно генерировать, и вроде как смысла нет.

Нужно. Зачем на каждой площадке их дублировать, если можно использовать готоые.

Я разработкой занимаюсь дома и в офисе. дома создал миграцию, сделал коммит tmp_название_задачи, запушил, в офисе миграцию накатил и дальше работаю.

Там все на много сложнее. У всех должны выполняться одинаковые миграции. Иначе можно конретно отгребти проблем.

Ну лично я принял волевое решение и вынес миграции из под гита, ибо действительно, если один работаешь над проектом, то еще куда ни шло, но нужно делать все то же, что на локалке, еще и на тестовом и боевом сервере, что уже увеличивает мне количество телодвижений. Кроме того миграции еще и в БД хранятся.Не каждое изменение идет на сервер, может передумаешь и ищменишь структуру еще раз ну и так далее.А если вдруг садишься за чужой проект и как начнешь фейкать и делать --delete-ghost-migrations после того, как склонируешь реп. Мне проще без миграций сделать syncdb (олд стайл, уже deprecated), и вести на каждом сервере свою историю миграций

Тут можно и даже желательно начать холивар ибо истина рождается в спорах

Обновлено 26 Фев. 2015, 15:20 alexscrat.

не знаю насчёт холиваров. Но вот мы работаем сейчас над одним проектом втроём. Кто-то один делает изменения в БД. Как сделать так, чтобы у всех остальных проект продолжил работать? Вручную добавлять поля или как? А ещё есть демо-сервер и боевой. На обоих есть уже множество данных, которые должны в БД оставаться. А боевой ещё и работать должен без перерывов. Так вот деплоится новая версия, а там структура БД другая, и как быть? Используем миграции, во всех случаях после изменения кода (хоть git pull у разработчика, хоть деплой), можно запустить миграцию, и БД автоматом примет нужную структуру. Как то же самое делать без миграций и без гемора — ума не приложу.

Ну лично я принял волевое решение и вынес миграции из под гита, ибо действительно, если один работаешь над проектом, то еще куда ни шло, но нужно делать все то же, что на локалке, еще и на тестовом и боевом сервере, что уже увеличивает мне количество телодвижений. Кроме того миграции еще и в БД хранятся.Не каждое изменение идет на сервер, может передумаешь и ищменишь структуру еще раз ну и так далее.

Это у вас процесс через ж. построен и вы пытаетесь его пофиксить аналогично. Если изменения не идут на сервера, что они делают в репо? Для таких изменений делаются отдельные ветки. В конце мержите окончательную миграцию. Хранения в БД истории миграций позволяет понять правильно ли прошли миграции. А так будет у вас история миграций из БД и как без кода миграции понять что вообще произошло и кто накосячил? А как же миграции данных? Как их генерировать?

Это у вас процесс через ж. построен и вы пытаетесь его пофиксить аналогично. Если изменения не идут на сервера, что они делают в репо? Для таких изменений делаются отдельные ветки. В конце мержите окончательную миграцию. Хранения в БД истории миграций позволяет понять правильно ли прошли миграции. А так будет у вас история миграций из БД и как без кода миграции понять что вообще произошло и кто накосячил? А как же миграции данных? Как их генерировать?

Дмитрий всё правильно говорит. Боевые миграции обязательно должны быть в репозитории. Промежуточные миграции, которыми вы тестируете некую функциональность надо хранить в своих отдельных ветках и при необходимости сливать в master .

Правда иногда бывают такие ситуации, что приходится впиливать большой функционал (это занимает достаточно длительное время) или одновременно работать над разными версиями БД. Для таких непростых проектов я создавал разные наборы конфигураций, нужная определялась текущей веткой репозитория. Таким образом, я спокойно переключался между ветками (например, между актуальной разработкой и веткой фичи), мог оперативно осуществлять поддержку боевого кода и разрабатывать новый функционал. А Django сама знала в какую базу данных надо сейчас смотреть.

Вообще, я всегда обеспечивал наличие на своей машине копии боевой БД, копии тестовой БД и пачку БД для веток. И перед вливанием кода очередной фичи в master и перед push ем его в главный репозиторий, я всегда прогонял тесты последовательно, на ветке фичи, затем на ветке тестовой машины, затем выкладывал код на тестовый сервер, где его протыкивал заказчик, после одобрения функционала, происходило тестирование на локальной мастер ветке с её БД и затем выкладывание на боевую машину. Этот может звучать сложно, но именно такой подход обеспечивал 146% гарантию того, что при обновлении сайт не грохнется и процессы у клиента не встанут.

Следует ли мне добавлять в файл файлы миграции Django .gitignore ?

В последнее время я получаю много проблем с git из-за конфликтов миграции, и мне было интересно, следует ли отмечать файлы миграции как игнорируемые.

Если да, то как мне добавить все миграции, которые есть в моих приложениях, и добавить их в .gitignore файл?

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

Если вы последуете этому процессу, у вас не должно возникнуть конфликтов слияния в файлах миграции.

При объединении ветвей управления версиями вы все равно можете столкнуться с ситуацией, когда у вас есть несколько миграций, основанных на одной и той же родительской миграции, например, если разные разработчики представили миграцию одновременно. Один из способов решить эту ситуацию - ввести _merge_migration_. Часто это можно сделать автоматически с помощью команды

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

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

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

Во-вторых, миграции часто содержат собственный рукописный код. Не всегда возможно автоматически сгенерировать их с помощью ./manage.py makemigrations .

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

Короче говоря, если вам важны производственные данные, проверьте свои миграции в системе контроля версий.

У нас, у команды разработчиков, тоже есть точно такая же проблема. Если работает один член makemigrations some_app , это затронет не только модели, находящиеся под его контролем, но и другие связанные модели. То есть файлы миграции (00 * _ *) в других приложениях будут изменены. И это вызывает множество проблем с конфликтами при отправке или извлечении из GitHub. Поскольку в настоящее время наша система не готова к производству, мы просто .gitignore файл миграции. Мы до сих пор не знаем, как решить эту проблему, когда система будет запущена в производство. Есть ли у кого-нибудь решения? Итак, если я хорошо понимаю, вам нужно вытащить миграции из своего проекта. Когда вы что-то меняете, вам нужно делать локальные миграции. Нажмите еще раз, и сервер сборки выполнит миграцию? (Очень важно, конечно, у всех есть хорошие версии) мы никогда не используем миграции django. все подключаются к центральной тестовой базе данных, если требуется изменение, при необходимости оно выполняется вручную на уровне базы данных. Этот метод хорошо работает, если система достаточно зрелая и не требует большого количества обновлений схемы базы данных. @ yltang52 В настоящее время мы тоже пытаемся разобраться в этом, не могли бы вы поделиться своими мыслями? Я думаю, что после того, как вы перейдете в производство, у вас не останется выбора, кроме как поддерживать эти миграции, чтобы упростить исправления и в целом упростить контроль версий. Мне также интересно, что вы делаете с данными начального состояния (например, с настройками, хранящимися в db). Как вы их поддерживаете? Я не думаю, что вам следует помещать файлы миграции в репо. Это испортит состояния миграции в среде разработки другого человека и другой производственной и сценической среде. (примеры см. в комментарии Sugar Tang). Достаточно файла моделей отслеживания.

Вы можете следовать приведенному ниже процессу.

Вы можете запускать makemigrations локально, и это создает файл миграции. Зафиксируйте этот новый файл миграции в репо.

На мой взгляд, запускать makemigrations в продакшн вообще не стоит . Вы можете запустить migrate в производственной среде, и вы увидите, что миграции применяются из файла миграции, который вы зафиксировали из локального. Таким образом можно избежать всех конфликтов.

В ЛОКАЛЬНОМ ОКРУЖЕНИИ , чтобы создать файлы миграции,

Теперь зафиксируйте эти вновь созданные файлы, как показано ниже.

В ПРОИЗВОДСТВЕННОЙ ENV выполните только следующую команду.

Должен ли я добавлять файлы миграции Django в файл .gitignore ?

Недавно у меня появилось много проблем с git из-за конфликтов миграции, и мне было интересно, стоит ли отмечать файлы миграции как игнорирующие.

Если да, как мне добавить все миграции, которые есть в моих приложениях, и добавить их в файл .gitignore ?

Файлы миграции для каждого приложения находятся в каталоге «миграции» внутри этого приложения и предназначены для фиксации и распространения как часть его кодовой базы. Вы должны сделать их один раз на своей машине разработки, а затем выполнить те же миграции на машинах ваших коллег, ваших промежуточных машинах и, в конечном итоге, на ваших производственных машинах.

Если вы будете следовать этому процессу, у вас не должно быть никаких конфликтов слияния в файлах миграции.

При объединении ветвей управления версиями вы все равно можете столкнуться с ситуацией, когда у вас есть несколько миграций, основанных на одной и той же родительской миграции, например, если бы разные разработчики вводили миграцию одновременно. Одним из способов разрешения этой ситуации является введение _merge_migration_. Часто это можно сделать автоматически с помощью команды

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

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

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

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

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

Короткий ответ Я предлагаю исключить миграции в репо. После слияния кода просто запустите ./manage.py makemigrations и все готово.

Длинный ответ Я не думаю, что вы должны помещать файлы миграции в репозиторий. Это испортит миграционные состояния в среде разработки другого человека и в других средах разработки и создания сценариев. (см. комментарий Sugar Tang для примеров).

На мой взгляд, цель миграций Django - найти разрывы между предыдущими модельными состояниями и новыми модельными состояниями, а затем сериализовать разрыв. Если ваша модель изменится после слияния кода, вы можете просто сделать makemigrations , чтобы найти пробел. Почему вы хотите вручную и осторожно объединить другие миграции, если вы можете добиться того же автоматически и без ошибок? в документации Django говорится:

Они * (миграции) * предназначены в основном для автоматического

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

Это хорошая тема о рабочем процессе. Я открыт для других вариантов.

Цитата из документов 2018 года, Django 2.0. (две отдельные команды = makemigrations и migrate )

Причина, по которой существуют отдельные команды для создания и применения миграций, заключается в том, что вы фиксируете миграции в своей системе контроля версий и поставляете их вместе с вашим приложением; они не только облегчают вашу разработку, они также могут использоваться другими разработчиками и в производстве.

Имея кучу файлов миграции в git, это грязно. В папке миграции есть только один файл, который вы не должны игнорировать. Этот файл является init .py файлом. Если вы его проигнорируете, python больше не будет искать подмодули внутри каталога, поэтому любые попытки импортировать модули потерпят неудачу. Таким образом, вопрос должен заключаться в том, как игнорировать все файлы миграции, кроме init .py? Решение: Добавьте «0 * .py» к файлам .gitignore, и это отлично сработает.

Надеюсь, это кому-нибудь поможет.

Обычно используемое решение заключается в том, что перед тем, как что-либо объединить с мастером, разработчик должен извлечь все удаленные изменения. Если существует конфликт в версиях миграции, он должен переименовать свою миграцию local (удаленная была запущена другими разработчиками и, возможно, в рабочей среде), на N + 1.

Во время разработки может быть хорошо просто не фиксировать миграции (не добавляйте игнорирование, просто не делайте add их). Но как только вы приступите к работе, они понадобятся вам, чтобы синхронизировать схему с изменениями модели.

Затем вам нужно отредактировать файл и изменить dependencies на последнюю удаленную версию.

Это работает для миграций Django, а также для других подобных приложений (sqlalchemy + alembic, RoR и т. Д.).

Я не могу представить, почему у вас будут конфликты, если вы как-то не редактируете миграции? Обычно это плохо кончается - если кто-то пропустит некоторые промежуточные коммиты, он не будет обновляться с правильной версии, а его копия базы данных будет повреждена.

Процесс, которому я следую, довольно прост - всякий раз, когда вы меняете модели для приложения, вы также фиксируете миграцию, а затем эта миграция не меняется - если вам нужно что-то другое в модели, тогда вы меняете модель и делаете новую миграцию вместе со своими изменениями.

В новых проектах часто можно удалить миграции и начать все заново с миграции 0001_ после выпуска, но если у вас есть производственный код, вы не сможете (хотя вы можете свести миграцию к одному).

Похоже, вам нужно настроить рабочий процесс git , а не игнорировать конфликты.

В идеале каждая новая функция разрабатывается в отдельной ветке и объединяется с запросом на получение ответа .

PR не может быть объединен, если есть конфликт, поэтому, кто должен объединить его особенность, должен решить конфликт, включая миграцию.

Вы можете следить за процессом ниже.

Вы можете запустить makemigrations локально, и это создаст файл миграции. Передайте этот новый файл миграции в репозиторий.

По моему мнению, вы вообще не должны запускать makemigrations в производстве. Вы можете запустить migrate в рабочей среде и увидите, что миграции применяются из файла миграции, который вы зафиксировали из локального файла. Таким образом, вы можете избежать всех конфликтов.

IN LOCAL ENV , чтобы создать файлы миграции,

Теперь зафиксируйте эти вновь созданные файлы, как показано ниже.

В ПРОДУКЦИИ ENV , запустите только приведенную ниже команду.

Gitignore миграции, если у вас есть отдельные БД для разработки, промежуточной и производственной среды. Для разработчиков цели Вы можете использовать локальную базу данных sqlite и играть с миграциями локально. Я бы порекомендовал Вам создать четыре дополнительных филиала:

Мастер - Чистый свежий код без миграций. Никто не связан с этой веткой. Используется только для проверки кода

Развитие - ежедневное развитие. Push / pull принимаются. Каждый разработчик работает над БД sqlite

Cloud_DEV_env - удаленная облачная / серверная среда DEV. Потяните только. Сохраняйте миграции локально на компьютере, который используется для развертывания кода и удаленных миграций базы данных Dev

Cloud_STAG_env - удаленная облачная / серверная среда STAG. Потяните только. Сохраняйте миграции локально на компьютере, который используется для развертывания кода и удаленных миграций базы данных Stag.

Cloud_PROD_env - удаленная облачная / серверная среда DEV. Потяните только. Сохраняйте миграции локально на компьютере, который используется для развертывания кода и удаленных миграций базы данных Prod

Примечания: 2, 3, 4 - миграции можно хранить в репозиториях, но должны быть строгие правила объединения запросов, поэтому мы решили найти человека, ответственного за развертывание, поэтому единственный человек, у которого есть все файлы миграции - наше развертывание -er . Он сохраняет удаленные миграции БД каждый раз, когда у нас появляются какие-либо изменения в Моделях.

Читайте также: