Должен ли я добавлять файлы миграции Django в файл .gitignore?
Я недавно получал много проблем git из-за конфликтов миграции и задавался вопросом, следует ли отмечать файлы миграции как игнорировать.
Если да, то как я могу добавить все миграции, которые у меня есть в своих приложениях, и добавить их в файл .gitignore?
Цитата из документации Django миграции:
Файлы миграции для каждого приложения находятся в каталоге "migrations" внутри этого приложения и предназначены для того, чтобы быть привязанным к его кодовой базе и распределенным как часть ее. Вы должны сделать их один раз на своей машине разработки, а затем выполнить те же самые миграции на компьютерах ваших коллег, на ваших станционных машинах и, в конечном итоге, на своих производственных машинах.
Если вы следуете этому процессу, вы не должны получать конфликты слияния в файлах миграции.
Чтобы устранить любые проблемы, которые у вас есть, вы должны указать, какой репозиторий или ветвь имеет авторитарную версию файлов миграции, а затем использовать механизм атрибутов git для укажите стратегию слияния "наши" для этих файлов. Это означает, что git всегда игнорирует внешние изменения этих файлов и предпочитает локальную версию.
Нет.
Я занимаюсь этим много раз, и я не могу, в моей жизни, найти случай, когда нам нужны миграции в репо.
Как я вижу, окончательная запись схемы models.py. Если я сменю изменение, а кто-то его потянет, все будет правильно, когда они запустит makemigrations и migrate. Нет необходимости определять, какая стратегия "нашего" для миграции.
Если нам нужно откат, мы возвращаем models и переносимся. Все хорошо, никаких проблем, никогда.
Нет жалобы на то, что поле уже существует и т.д.
Интересно, может ли кто-нибудь дать мне конкретный случай, когда мне будет полезно объединить другие файлы миграции разработчиков, прежде чем я смогу приступить к работе. Я знаю, что документы говорят, что я должен, поэтому я так и предполагаю. Но я никогда не встречал даже одного.
Кто-нибудь?
Вы можете выполнить описанный ниже процесс.
Вы можете запустить makemigrations локально, и это создаст файл миграции. Зафиксируйте этот новый файл миграции для репо.
По-моему, вы не должны запускать makemigrations в производстве вообще. Вы можете запустить migrate в процессе производства, и вы увидите, что миграция применяется из файла миграции, который вы проверили, из локального. Таким образом, вы можете избежать всех конфликтов.
Похоже, вам нужно настроить рабочий процесс git, вместо того чтобы игнорировать конфликты.
В идеале каждая новая функция разрабатывается в другой ветке и объединяется с запросом pull.
PR не может быть объединен, если есть конфликт, поэтому ему необходимо объединить свою функцию, чтобы разрешить конфликт, включая миграции.
Я не могу представить, что почему у вас появятся конфликты, если вы каким-либо образом не редактируете миграцию? Обычно это заканчивается неудачно - если кто-то пропускает некоторые промежуточные коммиты, то они не будут обновляться с правильной версии, и их копия базы данных будет повреждена.
Процесс, который я выполняю, довольно прост - всякий раз, когда вы меняете модели для приложения, вы также совершаете перенос, а затем , что перенос не изменяется - если вам нужно что-то другое в затем измените модель и выполните новую миграцию вместе с изменениями.
В проектах с новыми проектами вы можете часто удалять миграцию и начинать с нуля с переносом 0001_ при выпуске, но если у вас есть производственный код, вы не можете (хотя вы можете скворовать миграции вниз на один).
Обычно используемое решение состоит в том, что, прежде чем что-либо объединяется в master, разработчик должен вытащить любые удаленные изменения. Если есть конфликт в версиях миграции, он должен переименовать его локальную миграцию (удаленный был запущен другими разработчиками и, возможно, в процессе производства), до N + 1.
Во время разработки может быть хорошо, чтобы просто не совершать миграции (не добавляйте игнорирование, а просто не add их). Но как только вы перейдете к производству, вам понадобятся они, чтобы синхронизация схемы с изменениями модели.
Затем вам необходимо отредактировать файл и изменить dependencies на последнюю удаленную версию.
Это работает для переноса Django, а также других подобных приложений (sqlalchemy + alembic, RoR и т.д.).