А про добавление колонок на больших таблицах — здесь хорошо описано:
Опыт 1440 миграций баз данных — habr.com/company/wrike/blog/414441
Колонка добавляется как nullable ну и дальше аккуратно заполняется.

Обычно делаем CREATE INDEX CONCURRENTLY — PG создает индекс без блокировки таблицы в реалтайме. Ну и медленнее он работает конечно.

Интересно, сможете показать исходники export?

А как вы это делаете?

Да, подходящий кейс

Когда проекту больше 5 лет и миграций за тысячу — как-то по другому надо

ORM в миграциях нужна не столько для «удобства», сколько для потенциальной возможности смены СУБД

В миграциях этого точно не нужно — они одноразовые.

Транзакции в DDL

НЕ все базы поддерживают транзакции на уровне запросов по изменению структуры БД.
Долго работал и мучался с MySQL, у которой этого не было. Как там сейчас уже не в теме.

А много не надо. Человек 4-6 за один раунд, а потом анализировать, пилить, и снова тестировать.

Репо приватный. Выложил сценарий в gist: https://gist.github.com/715534

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

На сценарии? Я не давал ссылку на сценарии? В посте я только опубликовал один кейс для примера. Или я что-то не понял?

Вот именно, что впечатления. Жду полноценный обзор :)

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

Я бы еще добавил неудобство работы с субмодулями, у которых тоже есть субмодули со своими субмодулями.

Git-way: один модуль — один репозиторий. Можно конечно объедить группу репозиториев в суперрепозиторий, но обновляться будет не совсем удобно. Не пробовал.
Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.

Давайте заканчивать с пустыми папками. Воспринимайте это как данность. Никто еще не умер от этого.
Пустые папки создаются только один раз при разворачивании проекта. А если вы это регулярно делаете, тогда это вопрос организации сборки и деплоя.

git stash save «my stash name»

> 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой)
Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.

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

> А топик «Git vs Hg» будет очевидно однобок
А ты все равно напиши с соответствующим дисклеймером. По крайней мере я смогу оценить его с точки зрения Git и оценить его (git) слабые стороны.

Да. У каждого СВОЙ локальный репозиторий со всей историей.
И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.