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

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

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

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

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

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

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

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

./manage.py makemigrations --merge

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

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

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

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

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

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

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

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

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

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

python manage.py makemigrations 
python manage.py migrate

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

git add app/migrations/...
git commit -m 'add migration files' app/migrations/...

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

python manage.py migrate

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

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

https://docs.djangoproject.com/en/2.0/intro/tutorial02/

TL; DR: зафиксируйте миграции, разрешите конфликты миграции, настройте рабочий процесс git.

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

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

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

Однако важно зафиксировать файлы миграции! Если возникает конфликт, Django может даже помочь вам решить эти конфликты ;)

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

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

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

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

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

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

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

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

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

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

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

2. Развитие - ежедневное развитие. Принято толкать / тянуть. Каждый разработчик работает над БД sqlite

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

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

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

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

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

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

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

Они * (миграции) * в основном автоматические

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

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