I think "number of commits" varies too much between different developers to be a meaningful comparison, I've seen some developers commit every time their code a

I think "number of commits" varies too much between different developers to be a meaningful comparison, I've seen some developers commit every time their code actually compiles, and other developers not commit until they're ready to push to main / remote branch. But yes, trunk based development is about avoiding long lived branches, reducing the pain of merges. Others think there is a contradiction there, that if they regularly merge from main to their long lived branches then they are avoiding merge hell, but they're not, because you can have the following situation: 1. Person A keeps long lived branch, "Feature X including refactor Frob" 2. Person B keeps long lived branch, "Refactor Y including Frob changes" 3. Person C makes regular commits to main. Persons A and B regularly merge the changes from main, thinking they are avoiding merge conflicts, and on a literal sense they are, but what will happen is that when they realise they have incompatible changes, there will be an incentive for them to rush their feature branch into main first, so that they don't feel responsible for sorting the merge conflicts that will happen. There will be a perverse incentive to dodge quality because they don't want the other side to get their branch in before them. Also, because both branches A and B are long-running, their incompatibility and conflicting nature can be hidden for a long time.