Я к тому, что они тратят на разработку не деньги издателя, а деньги «бейкеров». И все эти покупки это вклад пользователя в «игру мечты». И пользователи готовы платить за это.
Какая разница чьи это деньги? Ну они выбрали такую модель монетизации проекта: брать деньги с БУДУЩИХ игроков. Вполне себе нормальная модель монетизации. Судя по цифрам — ничуть не хуже модели с инвесторами.
Но от того, что деньги они получают с конечных пользователей ДО выпуска продукта, это не перестает быть монетизацией
«Монетизация» !== «pay-to-win». Монетизация — это модель получения денег. И «нагиб за бабло», и «за бабло только бесполезные (но миленькие) рюшечки», и все промежуточные варианты — это все монетизация
Команда у нас действительно не большая, но над одной задачей бывает работают несколько разработчиков.
О таких калечащих изменениях обычно сообщается всем и заранее. Все приблизительно в курсе, кто чем занимается, поэтому если есть необходимость что-то поменять, то об этом сообщают людям, которых это может затронуть.
Не понятно, чем в данном случае ребейз от мержа будет отличаться? Только тем, что семантический конфликт будет зарыт внутри мерж-комита, а не идти отдельным?
Они будут не меньше, а все те же 1..N на каждый конфликтный файл.
Это будут уже другие конфликты. И высока вероятность, что их вообще не будет.
Я не утверждаю, что затраты всегда меньше, я говорю, что они с большой вероятностью будут меньше.
Похоже, что у нас слишком разный паттерн использования гита и продолжать спор смысла нет
Вот именно, ситуация когда разработчик не знает как правильно решить конфликт бывает гораздо реже (голова у тимлида не резиновая, тут Вы верно заметили).
Для решения конфликта тимлид наверняка привлечет разработчика ветки. Так почему бы разработчику самому не решать конфликты, без привлечения тимлида?
Описываемая Вами ситуация для нашей команды экстраординарная (если для Вас это норма — искренне Вам сочувствую). Поэтому накладные расходы на повторный ребейз и ревью не нами учитываются (к тому же они весьма вероятно будут значительно меньше).
Не знаю как у Вас построен процесс, а у нас в мастер вливает только тимлид. Владелец ветки перед передачей на слияние ребейзит ветку от мастера и решает конфликты, если они есть. Тимлиду же остается только влить изменения (после ревью). Конфликт решить проще разработчику, нежели тимлиду.
когда одновременно есть десяток-два веток становится сложно в этом ориентироваться. И не всегда все ветки вливаются в мастер, периодически фичи вливаются в фичи, особенно если над одной большой задачей работает несколько разработчиков.
Асинхронный PHP и история одного велосипеда
Новый комплект для Star Citizen обойдется в $27 тысяч
Какая разница чьи это деньги? Ну они выбрали такую модель монетизации проекта: брать деньги с БУДУЩИХ игроков. Вполне себе нормальная модель монетизации. Судя по цифрам — ничуть не хуже модели с инвесторами.
Но от того, что деньги они получают с конечных пользователей ДО выпуска продукта, это не перестает быть монетизацией
Новый комплект для Star Citizen обойдется в $27 тысяч
Книга «Hello World! Занимательное программирование»
Книга «Hello World! Занимательное программирование»
Разработка системы синхронизации в реальном времени с использованием SockJS, Django, Tornado и ZeroMQ
Стартап-ловушка
Допускаю, что в российских реалиях это корректно, но уверен, что Дядюшка Боб имел в виду двойную запись, а не двойную бухгалтерию :)
«Майкрософт» сменил поставщика модуля проверки правописания для «Офиса-2013» (зря)
«Майкрософт» сменил поставщика модуля проверки правописания для «Офиса-2013» (зря)
Если кому интересно, инструкции по установке и отчету можно тут посмотреть: www.informatic.ru/libre-beta
Git Rebase: руководство по использованию
Git Rebase: руководство по использованию
Git Rebase: руководство по использованию
Git Rebase: руководство по использованию
О таких калечащих изменениях обычно сообщается всем и заранее. Все приблизительно в курсе, кто чем занимается, поэтому если есть необходимость что-то поменять, то об этом сообщают людям, которых это может затронуть.
Не понятно, чем в данном случае ребейз от мержа будет отличаться? Только тем, что семантический конфликт будет зарыт внутри мерж-комита, а не идти отдельным?
Git Rebase: руководство по использованию
Git Rebase: руководство по использованию
Это будут уже другие конфликты. И высока вероятность, что их вообще не будет.
Я не утверждаю, что затраты всегда меньше, я говорю, что они с большой вероятностью будут меньше.
Похоже, что у нас слишком разный паттерн использования гита и продолжать спор смысла нет
Git Rebase: руководство по использованию
Для решения конфликта тимлид наверняка привлечет разработчика ветки. Так почему бы разработчику самому не решать конфликты, без привлечения тимлида?
Git Rebase: руководство по использованию
Git Rebase: руководство по использованию
Git Rebase: руководство по использованию
Не знаю как у Вас построен процесс, а у нас в мастер вливает только тимлид. Владелец ветки перед передачей на слияние ребейзит ветку от мастера и решает конфликты, если они есть. Тимлиду же остается только влить изменения (после ревью). Конфликт решить проще разработчику, нежели тимлиду.
Git Rebase: руководство по использованию