Everyone knows what GitFlow is and there is nothing in GitFlow which says your feature branches should be long lived.
But trunk based development is comparatively undefined.
The problem with any form of collaborative development is that two people working on one thing need to take each other changes into account if they want the whole thing to work.
That means the longer you keep your work to yourself the more problems you will have when you come to merge it into everyone else's changes.
Branching solutions like GitFlow have been developed to help with this problem. They allow you to work on your thing and manage the merging in of other changes over time to minimize the problem of the 'big merge'.
Frankly, the trunk based development approach as laid out by https://trunkbaseddevelopment.com/ boils down to "make smaller feature branches!"
You can do that with any branching model. The main difference in their diagrams is the lack of a development branch. But given the presence of release branches and the common lack of any work on master in GitFlow I don't think this will make much of a practical difference.
"Smaller Feature Branches" is a fine goal, but the purpose of branching models is to help you when you can't avoid them! TBD is not clear on how it solves actual real life problems
The main reason for people looking at TBD is that Google has said they do it. But a closer inspection of what they actually said leads me to believe that what they do is not really comparable to 'using git with no branches'
They started off with Perforce.
If you have ever used perforce you will know that it is one step above Visual Source Control. Branches in perforce are not like branches in git
They now have a custom source control system
So terms like repository, branching and committing don't mean the same as in git
They have 25000 developers and do 16000 commits each day.
This is a super high number for a single repository. But a super low number per developer. I did at least 20 commits today and it was a (very) slow one.
Every commit goes through code review
OK so here we get to the detail. Basically these commits are more like feature branch merges rather than commits. Each developer works on a 'local copy' (feature branch) which when completed is submitted for review and merging
So the big question which doesn't seem to be answered is:
- If there are 666 commits per hour and it takes 1.5 days to get my code committed. How do you merge it with the 23976 commits from other developers which happened since I started coding?
Reading between the lines, I think we can assume that:
- Their 'monolith' 'single repository' is not a single compiled application
- There are automated ways of determining if there is a potential merge conflict and altering the developers. Essentially allowing them to 'lock' sections of code
So in summary I would answer your question by saying, we all have the same problem and doing smaller changes solves it.