В django в чем разница между mergemigrations и squashmigrations?

Предположим, что в папке migration имеются следующие миграции.

./foo
    ./migrations
        0001_initial.py
        0002_userprofile.py
        0003_article.py
        0004_auto_add.py

выше заказанные до сих пор? Так как мы работаем в команде.

• Разработчик1 работает над функциями article и создал миграцию 0005_add_name_in_article.py
• Разработчик2 работает над функциями userprofile и создал 0005_add_mobile_in_userprofile.py
• Developer3 работает над функциями category и создал 0005_category.py
.

Сейчас возникла ситуация, когда

• Developer1 объединит код в ветку develop, файл миграции будет иметь вид

./foo
    ./migrations
        0001_initial.py
        0002_userprofile.py
        0003_article.py
        0004_auto_add.py
        0005_add_name_in_article.py

• Developer2 объединит код в ветку develop, файл миграции будет иметь вид

./foo
    ./migrations
        0001_initial.py
        0002_userprofile.py
        0003_article.py
        0004_auto_add.py
        0005_add_name_in_article.py
        0005_add_mobile_in_userprofile.py

Здесь последние две миграции имеют одинаковую зависимость, и это нарушает порядок миграции, в то время как Developer2 после слияния develop ветви django предоставит хит для merge миграции. После выполнения команды Django создаст новую миграцию, 0006_merge_add_name_in_article_add_mobile_in_userprofile.py, которая представляет собой слияние 0005_add_name_in_article.py и 0005_add_mobile_in_userprofile.py
. Файл содержит

  dependencies = [
        ('app_name', '0005_add_name_in_article'),
        ('app_name', '0005_add_mobile_in_userprofile'),
    ]

Теперь локальная ветвь Developer2 имеет следующие миграции.

./foo
    ./migrations
        0001_initial.py
        0002_userprofile.py
        0003_article.py
        0004_auto_add.py
        0005_add_name_in_article.py
        0005_add_mobile_in_userprofile.py
        0006_merge_add_name_in_article_add_mobile_in_userprofile.py

Теперь Разработчик2 поднимет PR и объединит, чтобы у другого разработчика не было конфликта.

• Тот же процесс сделает Разработчик3 для избежания конфликта миграции.

Что такое "миграция слиянием"?

Основной целью миграции слиянием является уменьшение конфликта на уровне базы данных при совместной работе. и он будет генерировать новый файл миграции для управления порядком миграций.

Что такое "миграция сквоша"?

Может возникнуть вопрос: сколько ненужных файлов будет создано для миграции?"

• В файле миграции merge не было выполнено ни одной операции.
• Могут быть таблицы, в которых вы добавили один столбец, затем удалили его, а затем снова добавили в таблицу, при этом могут быть созданы различные миграции. Основной целью сминания миграции является оптимизация файла миграции. Но перед сминанием миграции, пожалуйста, обратитесь к docs, так как в некоторых случаях это может быть громоздким или вызвать конфликт миграции.
.

Можем ли мы выполнять эти команды через конвейер вместо того, чтобы каждый разработчик в нашей команде делал это вручную?

Нет, в соответствии с приведенным выше примером использования миграции merge и squash, мы не можем сделать это на pipeline, так как ответственность разработчика за поддержание миграции в порядке, и согласно сообществу django все миграции должны быть синхронизированы в команде, поэтому мы не можем сделать это на pipeline.