После того, как вы отметите миграцию в систему управления версиями, я бы рекомендовал не изменять их. Я делаю редкое исключение, если в нем есть ошибка, но это довольно редко (возможно, 1 из 100).
Причина в том, что когда они выходят в дикую природу, некоторые люди могут ими управлять. Они записаны как завершенные в БД. Если вы измените их и зарегистрируете новую версию, другие люди не получат выгоду от изменения. Вы можете попросить людей откатить некоторые изменения и повторно запустить их, но это не отвечает цели автоматизации. Сделано часто, это становится беспорядком. Лучше оставить в покое.
Когда вы получаете большое количество миграций, оно может начать чувствовать себя неловко. В общем, тем не менее, вы не будете так много управлять. Единственное место, где мы это делаем, - это наш сервер интеграции, который отбрасывает и воссоздает базу данных при каждом запуске. Так что вы можете просто не открывать этот каталог и делать вид, что его там нет.
Существует практика консолидации миграций. Для этого просто скопируйте текущую схему в миграцию и удалите все предыдущие миграции. Тогда у вас будет меньше файлов для управления, и тесты могут выполняться быстрее. Вы должны быть осторожны, особенно если у вас автоматически выполняются миграции в рабочей среде. Обычно я заменяю миграцию, которая, как я знаю, у всех запущена, новой схемой. У других людей есть немного другие способы сделать это.