Как работать с Git на стадии эксперементов с прототипированием/моделированием

migrations надо хранить в репе.

Я однажды игрался со сторонним модулем, потом удалил его. Через origin развернул на тестовый деплой и отгреб - migrations не проходили пока я не поставил уже ненужный мне модуль. Вот как с таким бороться?

Сразу скажу - я далеко не git pro.

Почему бы не сделать clone твоей локальной репы в соседний каталог и не проводить эксперименты там? Если не понравилось - потом снести его вообще. Если понравилось - оставать в нем работать или смержить.

А надо ли?
Что там полезного кроме __init__.py может лежать для деплоя?

Дофига всего.

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

class Migration(SchemaMigration):

    def forwards(self, orm):
        # Adding field 'Gadget.slug'
        db.add_column(u'catalog_gadget', 'slug',
                      self.gf('django.db.models.fields.SlugField')(default='', max_length=50),
                      keep_default=False)
        from django.template.defaultfilters import slugify
        for gadget in orm.Gadget.objects.all():
            gadget.slug = slugify(gadget.title)
            gadget.save()

И такого кода и случаев есть масса в любом проекте.

Ес-но это всё надо хранить в репе.

Но надо ли этот класс засовывать в migrations джанги?
Массы такого кода это признак или говнокода или хренового планирования, на мой скромный взгляд.

https://git-scm.com/docs/git-submodule

А что ты предлагаешь делать вот в том примере? Ручками из manage.py shell прописывать этот slug на каждой инсталяции проекта, как раньше делали?

Это вообще то, для чего миграции и нужны. Не всегда автосгенеренного достаточно, бывают вообще хитрые случаи.

хренового планирования

Это признак реального проекта, который развивается, требования/задачи меняются и т.п.

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

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

Хотя я никому не запрещаю так делать. Если кто-то из компетентных архитекторов принял такое решение — значит в других решениях приняты достаточные компромиссы для работоспособности этого решения.

Но навязывать его как самое лучшее и единственное из возможных ни в коем случае нельзя.

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

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

http://south.readthedocs.org/en/latest/tutorial/part3.html#data-migrations

If you open up the file, you’ll see that South has made the shell of a migration; the models definitions are there, the forwards() and backwards() functions are there, but there’s no code in either. We’ll write some code to port the passwords over in the forwards function:

И пример аналогичный тому что я приводил.

хм. и на это стадии в БД уже есть какие-то ценные данные, которые необходимо реструктуризировать миграциями? я б забил, и делал sql reset, пока действительно не появятся пользователи кроме тебя. да и потом бы старался «схлопавать» миграции до вида релиз-релиз.

Пока нет пользователей, кроме тебя, конечно можно sql reset делать. Хотя это и менее удобно - придется заново пользователя делать, какими-то тестовыми данными заполнять.

Но когда сайт уже работает, туда тоже надо изменения вносить, добавлять новые фичи или менять имеющиеся в соотв. с пожеланиями заказчика. Раньше приходилось ручками alter table делать и за всем следить.

до вида релиз-релиз.

Обычно есть dev сервер отдельно и продакшн, На dev сервере надо тестировать всё и не только тебе.

Какой профит от гита на стадии прототипирования?

Ну а почему бы нет?
Это всетаки история изменений, для чего git и предназначен.

Не просрать то, что уже успел высрать.

Пока у меня простой init-скрипт с тестовыми данными (про fixtures я узнал уже после его написания).

Пока делаю так - поиграл с кодом, дропнул миграции и базу, запустил инит-скрипт, смотрю на результат.

Ручками, ручками...

Какой профит от гита на стадии прототипирования?

Я вожусь с кодом на работе и дома, периодически сливаю код на тестовый деплой. Как без cvs то?

Для этого есть другие инструменты. Профит именно гита в чем?

vcs. cvs это конкретная система контроля версий, устревшая.

Лично для меня: я (для «приглядеться») не редко шпилю в несколько веток, затем выбираю лучший вариант, остальные тупо отмирают.

Папку расшарь/работай по RDP/выкладывай на дропбокс.
Короче, профитов именно гита я не вижу. Так что, если юзаешь гит для хранения и распространения исходников, то зачем заморачиваться практиками? Хоть в архивируй актуальное состояние исходников и коммить архив.

Спасибо, да - vcs

А при чём тут туториал по south и джанга?

Please note that South is now end of lifed in favour of the ​new migrations framework in Django 1.7, which is based on South but with significant design improvements

Ну это вот правильный же вариант использования гита, если я правильно тебя понял. Но у ТС, на сколько я его понял, вообще пока нет ничего полезного в гите и он хочет в нем ворочать прототип.

Потому что изменения в моделях и так есть в истории, незачем историю автогенерируемой истории истории хранить ещё дополнительно.

Ты троллишь так? До недавнего времени south был де-факто стандартным средством миграций.

Хорошо, вот тебе ссылка на новые миграции, абсолютно тоже самое

https://docs.djangoproject.com/en/1.8/topics/migrations/#data-migrations

Опять же ты пишешь код в миграциях, так задумано.

И вот ещё

https://docs.djangoproject.com/en/1.8/howto/writing-migrations/

На любом этапе полезно посмотреть историю измнений и иметь возможность откатиться.

Migrations that alter data are usually called “data migrations”; they’re best written as separate migrations, sitting alongside your schema migrations.

as separate

Перевожу: держите свои костыли отдельно.
Так зачем запихивать всю дирректорию migrations целиком?

Они связаны с остальными миграциями - как минимум порядок выполнения должен быть таким же.

А новые миграции зависят от предыдущих, если ты на разных деплоях сделаешь makemigrations в разный момент состояния кода, то у тебя миграции будут выглядить по-разному, иметь разный номер и порядок и всё сломается. Поэтому их делают на одной машине - где ты пишешь код и код миграций и хранят в vcs.

Ну это если вы под прототипом имеете в виду одну из первоначальных версий своего продукта, т.е. код, который попадет в итоговую версию. ТС продумывает модель и структуру каталогов, он еще с архитектурой решения не определился, все плюшки гита тут во вред. Ему нужна замена флешки.

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

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

Смысл в отделении скриптов написанных человеком от автоматически сгенерированных.

migrations надо хранить в репе.

А надо ли?
Что там полезного кроме __init__.py может лежать для деплоя?
держите свои костыли отдельно.
зачем запихивать всю дирректорию migrations целиком?

Я вот про это спрашиваю. Какой смысл разделять миграции схемы и данных на «в репе» и «не в репе», если в новой версии продукта должна быть как миграция схемы, так и миграция данных?

data migrations должны применяться строго в определенном состоянии схемы, иначе они работать не будут. В другом состоянии у тебя схема другая и поля могут по-другому называться или отстутствовать.

Смысл в отделении скриптов написанных человеком от автоматически сгенерированных.

Ты manage.py startapp тоже вручную везде делаешь вместо хранения результата его работы в vcs? Какой смысл не хранить миграции, а генерировать каждый раз заново? Тем более что это может дать разный результат и ломает data migrations, они привязаны к определенному именам сгенерениванных миграций через run_before, dependencies.

И есть ещё всякие моменты вот, например https://docs.djangoproject.com/en/1.8/howto/writing-migrations/#migrations-th...

Ну не знаю, я согласен с pawnhearts. Как наспоритесь, кастаните, почитаю.

Мне с ним спорить уже надоело.

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

Какой подход выбрать — решать архитектору проекта.

С моей колокольни
на глаз

Ну охренеть теперь аргументы.

в моём случае

Т.е. в мечтах, не имеющих ничего общего с реальностью.

аккуратность выше за счёт угнетения говнокодеров и усложнения планирования

Сказал говнокодер, не сумевший объяснить как он собрался планировать эту ситуацию.

Ты говоришь с автором вот этого http://govnokod.ru/19103

Сношайтесь тут дальше без меня

Веселый тред, хорошо показывает уровень Goury.

По теме треда - а в чем «гемор со слиянием»?

А кастовал зачем?

Просто чтобы ссылка красивая была.

Пробовал делить все эксперименты на бранчи, но в итоге еще больше запутываешься

Вангую что имена бранчей там из разряда test1 tmp2 delme