Мне любопытно, как другие разработчики Django управляют своими миграциями базы данных с Югом при разработке с несколькими ветвями кода. Позвольте мне привести примерный сценарий.
Скажите, например, вы начинаете разработку с вашего основного ствола. Вы создаете ветвь А из ствола. На этом этапе последняя версия миграции для app_1
равна 0010.
Затем вы создаете перенос для app_1
в соединительной линии, который создает файл миграции 0011_add_name_column
. Между тем, в ветке A другой разработчик создает другой файл миграции для того же app_1
в ветке A: 0011_increase_value_column_size
.
Филиал A в конечном итоге объединяется обратно в багажник. Когда это произойдет, скажем, последняя версия миграции в app_1
в ветке A - 0020
, а в тубе последняя версия - 0018
, и все они разные. Как вы можете видеть, состояние файлов миграции перепутано с версии 0011
, когда ветвь была разветвлена с соединительной линии.. и все они конфликтуют при слиянии.
Согласно Южному учебнику, единственный способ справиться с этим делом - разрешить все конфликты вручную. Однако это не является желательным решением, если количество конфликтов значимо. Как вы обычно справляетесь с этой ситуацией или даже избегаете ее в первую очередь?