Я читаю об EF Migrations и начинаю играть с этим.
Я использую Git для управления исходным кодом, и каждый раз, когда я начинаю работать над новой функцией, я создаю ветку.Причина этого заключается в том, что если мне нужно быстро перейти к другой функции или сделать важное исправление, которое необходимо удалить, я могу просто изменить ветки и продолжить работу.
В настоящее время у меня есть настройка приложениятак что, если я не нахожусь в производственной среде (web.config appsetting), он очищает базу данных и переустанавливает ее, если произошли изменения в модели данных (Code-first).Я думал, что миграции будут хороши тем, что мне не придется полностью уничтожать мои данные при малейшем изменении модели.
К сожалению, я вижу некоторые признаки того, что это не так удобно для управления версиями, как я надеялся,Например, если я добавлю новый столбец в свою модель данных, обновлю базу данных, а затем решу отменить мои изменения, EF по-прежнему будет знать об изменениях модели, поскольку сохраняет их в самой базе данных.
Кажется, что нет чистого способа сказать, чтобы понизить версию db, когда ветвь впервые произошла, а затем перенести ее туда, где находится db в ветке, над которой я решил работать без МНОГОзапоминание и ручное отслеживание.
У кого-нибудь есть стратегия использования миграций в нетривиальном сценарии разработки с контролем версий?