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