LINUX.ORG.RU

История изменений

Исправление theNamelessOne, (текущая версия) :

В видео вроде про это нет, но даже теоритически тут не нужен SCM в традиционном смысле, у тебя по-сути нет конфликтов, если два разработчика сделали изменения одной функции - они существуют как отдельные версии

Если фичефлаги использовать в таком ключе, то при параллельной разработке даже небольшой командой разработчиков у тебя совсем скоро эти фичефлаги разрастутся до сотен (может быть и тысяч).

и в итоге во время ревью можно оставить одну.

Ну ок. А вдруг ты через полгода захочешь вернуть старую версию кода? Что вообще делать с историей? Оставлять мёртвый код на случай, если вдруг он тебе понадобится? Как делать бисекты для новых багов?

Исходная версия theNamelessOne, :

В видео вроде про это нет, но даже теоритически тут не нужен SCM в традиционном смысле, у тебя по-сути нет конфликтов, если два разработчика сделали изменения одной функции - они существуют как отдельные версии

Если фичефлаги использовать в таком ключе, то при параллельной разработке даже небольшой командой разработчиков у тебя совсем скоро эти фичефлаги разрастутся до сотен (может быть и тысяч).

А что, если разработчики захотят одновременно поработать над одним участком кода?

и в итоге во время ревью можно оставить одну.

Ну ок. А вдруг ты через полгода захочешь вернуть старую версию кода? Что вообще делать с историей? Оставлять мёртвый код на случай, если вдруг он тебе понадобится? Как делать бисекты для новых багов?