squash hotfix в develop (нечего ему неприкаянным висеть)
git push -f
Все разработчики делают git fetch && git rebase -i origin/develop
PS: Не подходит для open-source проектов, где мы не можем заставить всех сделать последний пункт. Впрочем, squash feature/hotfix бранчей нередко требуют и в open-source проектах. И это — правильно
Вас никто не заставляет заходить в фичеветки — смотрите мерж-коммиты
Commit Hell
Это тестовый пример обратной реинтеграции изменений без rebase. 3 разработчика работали в 3 ветках и периодически подтягивали изменения друг-друга при помощи merge. Внимательный читатель несомнено обратит внимание на то, что в данном commit hell'е непосредственно в ветку merge-rebase-3 сделан один (ОДИН!) коммит.
Я очень против «чистоты истории коммитов», удаления мердженных фича-веток, ребейза, переписывания истории (вообще фу). Причина этому одна — я не вижу никаких плюсов для этого на практике.
Напоминает религиозные страхи. А на самом деле.
Одно из главных правил git — commit frequently (комитьтесь чаще). Пачка из 100+ коммитов в develop ветке — отличный подарок всем, кто в отличие от вас хотят читать историю.
Набор коммитов в фича-ветке — это мысли разработчика при работе над фичей. На кой черт мне нужно читать потом в главной ветке весь этот поток сознания?
Неудаление смердженных веток — это вообще аут. У нас сейчас в JIRA id тасков перевалило за 4700. По-вашему у меня в репозитории должно быть 4700 старых веток?
Представьте ситуацию: я ваш заказчик, вы имеете в develop ветке фичи: 1 (13 коммитов), 2 (27 коммитов), 3 (5 коммитов), 4 (19 коммитов), 5 (2 коммита). Я прошу: задеплой мне прямо сейчас на прод фичи 3 и 5. Остальные — не нужно, я хочу протестировать их отдельно. Ваши действия?
Насколько я понял, Command не может влиять на состояние CommandBus (например, хендлить какие-то другие команды). Как в таком случае мне быть в таком случае:
Читаем JSON файл с сервера и парсим (ReadFileFromServerCommand)
В файле содержатся имена других файлов для парсинга (например next, prev). По идее я должен создать новую команду ReadFileFromServerCommand с новыми аргументами и засунуть ее в CommandBus. Но я не могу из комманды влиять на состояние CommandBus.
CommandBus — частный случай EventSubscriber. В CommandBus всегда 1 обработчик, а в EventSubscriber — любое число обработчиков (в т.ч. — 0). То есть CommandBus гарантирует а) что кто-то обработает вашу команду, б) что ее обработают не более 1 раза
Sublime просто пишет во временный файл при каждом действии, так что даже если во время работы мигнет свет или еще что, то файл не потеряется. А в VS ни один из вариантов этого не даст. Разве что autoSaveDelay ставить в 1
Правила, технологии, интернеты, спутники… А Коста Конкордия в 100 метрах от берега чвякнулась и 32 человека на небеса отправились. А если бы в 200 метрах? Половина пассажиров пузыри пустила бы?
Прирост производительности = Время отклика без кэширования/Время отклика с кэшированием = 1589/6 что приблизительно в 265 раз быстрее или прирост производительности = ((Время отклика без кэширования- Время отклика с кэшированием)/ Время отклика с кэшированием * 100) приблизительно на 26 383% быстрее.
Выглядит круто, но статья про L2 кэш, а вычисления для случая, когда L1 также пуст. В реальности же увеличение производительности не будет больше, чем число нод. А если еще и sticky-session использовать, то того меньше.
Про эту либу слышал, сама по себе ссылка не приоткрывает завесу тайны, но пошел там по ссылкам и нашел-таки реальный пример!!! Так что спасибо за наводку
Извините, представить получается с трудом. Если система не работает с какими-то данными, то это мертвые данные — зачем они нужны? Если ваш тест не покрывает какую-то функциональность, а работа с такими данными ведется, то это неполный тест — толку от такого нет.
У меня на проекте — так:
PS: Не подходит для open-source проектов, где мы не можем заставить всех сделать последний пункт. Впрочем, squash feature/hotfix бранчей нередко требуют и в open-source проектах. И это — правильно
Так ведь squash как раз и дает читабельность истории.
git reflog
Это тестовый пример обратной реинтеграции изменений без rebase. 3 разработчика работали в 3 ветках и периодически подтягивали изменения друг-друга при помощи merge. Внимательный читатель несомнено обратит внимание на то, что в данном commit hell'е непосредственно в ветку merge-rebase-3 сделан один (ОДИН!) коммит.
Напоминает религиозные страхи. А на самом деле.
Напомнило
Насколько я понял, Command не может влиять на состояние CommandBus (например, хендлить какие-то другие команды). Как в таком случае мне быть в таком случае:
За статью, большое спасибо
Уже есть и в Tactician
Было когда-то на Хабре
UP: Таки не я один.
Кто такая эта "Зая"? Я бы не советовал пускать Зай и Мась в продакшн :)
Выглядит круто, но статья про L2 кэш, а вычисления для случая, когда L1 также пуст. В реальности же увеличение производительности не будет больше, чем число нод. А если еще и sticky-session использовать, то того меньше.