С помощью этого - никак.

Доброго времени суток.
Столкнулся с "конфликтом миграций".
локально конфликт решается без каких либо проблем, а вот что делать с этим же конфликтом на удалённом сервере, не совсем понятно.
Нашёл одно из решений - это решать конфликт локально и добавить в гит репозиторий файлы миграции, а на удалённом сервере сделать только manage.py migrate без без предворительной команды manage.py makemigrations.
Вопрос в следующем, насколько это правильное решение? Хранить файлы миграции в репозитории? Или есть нормальный способ решение данной проблемц?

всем привет подскажите как это использовать для авторизации через телегу https://github.com/RealmTeam/django-rest-framework-social-oauth2

Доброго времени суток.
Столкнулся с "конфликтом миграций".
локально конфликт решается без каких либо проблем, а вот что делать с этим же конфликтом на удалённом сервере, не совсем понятно.
Нашёл одно из решений - это решать конфликт локально и добавить в гит репозиторий файлы миграции, а на удалённом сервере сделать только manage.py migrate без без предворительной команды manage.py makemigrations.
Вопрос в следующем, насколько это правильное решение? Хранить файлы миграции в репозитории? Или есть нормальный способ решение данной проблемц?

Доброго времени суток.
Столкнулся с "конфликтом миграций".
локально конфликт решается без каких либо проблем, а вот что делать с этим же конфликтом на удалённом сервере, не совсем понятно.
Нашёл одно из решений - это решать конфликт локально и добавить в гит репозиторий файлы миграции, а на удалённом сервере сделать только manage.py migrate без без предворительной команды manage.py makemigrations.
Вопрос в следующем, насколько это правильное решение? Хранить файлы миграции в репозитории? Или есть нормальный способ решение данной проблемц?

Хранить миграции в репозитории - единственное правильное решение для 99% проектов.

Это прямым текстом написано в документации: https://docs.djangoproject.com/en/3.1/topics/migrations/#workflow

А что является 1%?

Хранить файлы миграции в репозитории и разрешать такие проблемы через эти миграции это норма

Интересно как они делали миграции, которые определенные махинации с данными выполняли 🤔

Хранить миграции в репозитории - единственное правильное решение для 99% проектов.

Это прямым текстом написано в документации: https://docs.djangoproject.com/en/3.1/topics/migrations/#workflow

Ребят подключил django-cors-header записал эти локалы, но у меня на порте 3000 не работает, та же ошибка с корсами, что не так, что скинуть?

Я встречал проекты, которые задеплоены под разные организации с минимальными, но отличиями в структуре (но с единой кодобазой). Они существовали в разных стейтах и там не пушили миграции в систему контроля версий. Я не буду говорить, что там это было правильным решением, но могу представить что какие-то проблемы они тем самым решали. Поэтому оставил 1% на всякие чудачества вроде этого

Может, потому что ты его не указал в корсах?

дело в том что пишет что он тип такое имя не зарегистрировано но сейчас перепроверил там на конце / стояла и это мешало

Сейчас добавил, но все равно та же ошибка