Это у вас процесс через ж... построен и вы пытаетесь его пофиксить аналогично. Если изменения не идут на сервера, что они делают в репо? Для таких изменений делаются отдельные ветки. В конце мержите окончательную миграцию. Хранения в БД истории миграций позволяет понять правильно ли прошли миграции. А так будет у вас история миграций из БД и как без кода миграции понять что вообще произошло и кто накосячил? А как же миграции данных? Как их генерировать?
Дмитрий всё правильно говорит. Боевые миграции обязательно должны быть в репозитории. Промежуточные миграции, которыми вы тестируете некую функциональность надо хранить в своих отдельных ветках и при необходимости сливать в master.
Правда иногда бывают такие ситуации, что приходится впиливать большой функционал (это занимает достаточно длительное время) или одновременно работать над разными версиями БД. Для таких непростых проектов я создавал разные наборы конфигураций, нужная определялась текущей веткой репозитория. Таким образом, я спокойно переключался между ветками (например, между актуальной разработкой и веткой фичи), мог оперативно осуществлять поддержку боевого кода и разрабатывать новый функционал. А Django сама знала в какую базу данных надо сейчас смотреть.
Вообще, я всегда обеспечивал наличие на своей машине копии боевой БД, копии тестовой БД и пачку БД для веток. И перед вливанием кода очередной фичи в master и перед pushем его в главный репозиторий, я всегда прогонял тесты последовательно, на ветке фичи, затем на ветке тестовой машины, затем выкладывал код на тестовый сервер, где его протыкивал заказчик, после одобрения функционала, происходило тестирование на локальной мастер ветке с её БД и затем выкладывание на боевую машину. Этот может звучать сложно, но именно такой подход обеспечивал 146% гарантию того, что при обновлении сайт не грохнется и процессы у клиента не встанут.
