Is infrequent syncing in DVCS trunk based development similar to a long-lived feature branch in GitFlow?

Question

I'm working on a project and trying to understand the differences and trade-offs between variations of trunk based development and feature branching like git flow so I can help implement an appropriate solution for the team.

Would the first diagram of GitFlow below also be a representation of Trunk Based Development? Not how TBD should be practiced (second image), but rather what would occur if two developers were working on their local copy of master and only infrequently merging / pushing with the remote master.

If the main benefit from TBD is to avoid semantic and textual merge conflicts that are difficult to solve by integrating frequently with the trunk then I see these benefits diminishing as merge frequency diminishes.

Most of the images of Trunk Based Development I look for contain references to short-lived feature branches but I want to better understand what committing directly to master would look like.

Images from https://martinfowler.com/bliki/FeatureBranch.html

I did find a reference that says that trunk-based development in DVCS is basically the same as feature branch development, the difference being where unmerged changes are stored (on a remote feature branch, or local copy of trunk). So if this is true, then the answer to my question would be 'yes', because infrequent merges on either a local trunk copy or remote branch would be long-lived branches.

https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/

Answer 1

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'

1. 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

2. They now have a custom source control system

   So terms like repository, branching and committing don't mean the same as in git

3. 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.

4. 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.