I just read this as an argument for tiny incremental changes and very short-lived branches. This can work well for a team that is very highly engaged and where

I just read this as an argument for tiny incremental changes and very short-lived branches. This can work well for a team that is very highly engaged and where Code Reviews get immediate attention. When I've worked for startups, I've seen this kind of usage out of git and it can be quite effective (no branches alive for more than a couple days + frequent rebasing in of upstream changes from main/master). Long-lived, all-encompassing feature branches are definitely an anti-pattern and they bit-rot unbelievably quickly, especially as team size grows. Some shops I've worked in still prefer them, though, because they demand zero dead code paths or half-baked features making it into the mainline (which are definitely their own risk of technical debt).