Дві гілки додали EF Core міграції. Як ви це розрулюєте?
Питання до тих, хто працює з EF Core у команді.
Уявімо звичайну ситуацію: є дві feature-гілки, в обох змінилась модель і з’явились свої міграції. Одну гілку вже змержили в develop, а через якийсь час доходить черга до другої.
Що у вас зазвичай відбувається в такому випадку?
Цікаво не стільки «як правильно», скільки як це реально працює у ваших командах. Робите rebase/merge і перестворюєте міграцію? Розрулюєте все вручну? Чи у вас процес побудований так, щоб такі ситуації майже не виникали?
Якщо стикались — особливо цікаво почути про останній реальний випадок: що сталося і що в результаті довелось робити.
3 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівНіяк.
Специфіка роботи з міграціями проста: якщо твої змінни не останні — то ти втрапив. Видаляєш свою міграцію (власне а чого в тебе написано міграції — в множинi? мержити до основного бранча більше однієї міграції за один раз — саме по собі не правильно, треба трансформувати в одну).
Далі підмерджуєш останні зміни (фіксаєш ентіті і контекст за необхідністю)... Створюєш нову міграцію, перетестовуєш все локально — і після того вже оновляюєш пр (ну або створюєш новий).
І так — увесь цей час молишся щоб ніхто знов поперд тебе не вліз.
Ну а взагалі (як писали вище) — ми ж працюємо в дружніх колективах з цікавими проектами, тому зазвичай або є спец-чатіки для такого, або (якщо колектив не сильно дружній) можна і репку заздалегіть залокати.
learn.microsoft.com/...-schemas/migrations/teams
Хороше питання, в свій час теж намагався знайти на нього відповідь. По факту стараємося попереджати одне одного про майбутні зміни в БД. Якщо потрібно це робити одночасно, то можемо зміну по БД винести в окремий мерж і швиденько влити в основну гілку.