база ничего не должна знать про твои бранчи. Зачем ей это?

Время создания миграции и время её применения на сервере (а их несколько обычно) сильно разные величины. Может и полгода пройти - ты уже забудешь про эту миграцию

сорри, не понял

в общем случае- я поменял что-то в модели, синкнул код у заказчика, сгенерил миграции и накатил их.

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

в общем случае накатывать миграции должен не ты, а специально обученный человек. Ему нужна одна команда. Если нужна дата миграция или не тривиальная, которая автоматом не может быть сгенериться (у меня каждая вторая обычно), то ты в пролете. Плюс миграции надо тестировать ибо это тоже код. С твоим подходом можно делать приложения аля hello world.

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

Теперь у нас всё очень похоже, но:
- на s3 всегда есть свежий дамп базы для текущей Dev ветки, все пляски с базой не нужны, просто скрипт разворачивает новую
- дата миграции импортируют libs, поэтому их тоже легко перегенеривает скрипт, который накатывает базу.

Вообще 0 телодвижений.

Дырок в дереве нет и история всегда линейная.

И в гите и в миграциях.

P.S. мёрж коммиты и мёрж миграции у нас запрещены.

Ну если вы любите доп. работу ради эстетического удовольствия наблюдать линейную историю - ваше дело 😊
Меня не очень коробят разветвления.

Я, к слову, за все эти годы так и не понял, зачем нужна эта линейная история. Все, что нужно - git blame + поменьше плясок вокруг мержей и ребейзов. На практике этот транк-бейзд девелопмент не сильно нужен

There is a story behind each cover...

Короче, при не линейной истории в миграциях, когда у тебя реально дерево, порядок выполнения этих миграций варьируется. Можно спокойно пропустить неявные связи, которые могут возникнуть между ними.

При установке у одного из 1000 заказчиков, они накатились в таком порядке, в котором ну никто не ожидал, что это возможно. И ладно бы оно упало. Просто тихо прошёл процесс, данные хитро покорраптились. В результате через неделю отвалилась совсем другое место в другом конце системы.

Типы данных, вариации значений всё норм, но в целом с точки зрения бизнеслогики несут бред. Запускаются совсем не те процедуры и т.д. Пока мы искали чё за дичь творится прошла неделя, за которую платили по sla.

После этого решили следить за линейной историей.

Все было бы здорово, если бы речь не шла о джанге, где можно руками дописывать депенденсы к миграциям. Ну, как бы ок: я видел компанию, где миграции делались не в коде, а в текстовом документе, который исполнялся по регламентной процедуре 🤷‍♂️

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

А разве алембик позволяет ветвить миграции? Вроде он ругается, когда такое встречает

Джанго позволяет

Ребейз не Гита, а дерева миграций. Чтобы не было двух параллельных веток, которые потом в head смыкаются.

Дело тут не в Django кстати. У alembic было бы так же.

Не в рамках одного приложения.

Хм, https://alembic.sqlalchemy.org/en/latest/branches.html
Не пользовался

Как интересно, в телеграм каналах реклама криптовалют сменилась на рекламу "стань погромистом, там ПЛАТЯТ"
пример:
https://t.me/rozetked/5185