Должен ли я добавлять файлы миграции Django в файл .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 и т.д.).