I really disagree. Feature branching is an invaluable aspect of development workflow. I agree that code isn't written in a vacuum and individual developers must be aware of everything else going on simultaneously to avoid disjointed software and the bloat that comes with development each developer trying to be independent.
However, feature branching is not the source of these problems. Poor communication is.
My teams are always checking out each other's feature branches to understand changes being made. WIP pull requests are made as soon as a feature's scaffolding is clear enough to be understood by another developer. Comments are made right away suggesting improvements, warning of pitfalls or inconsistencies, or criticizing the entire approach. As commits roll in, particularly affected parties subscribe to notifications so they can see what's changing and discuss.
When developing, I spend at least 20% of my time in other people's branches, piecing together the way everything will work. When I notice divergence between the branches, I start a lengthy thread on Slack and we figure out how to tighten up our architecture.
What about when developing highly-interdependent features? Keep in mind that they're feature branches, not developer branches, and don't exclude cooperative development by multiple developers on a single branch. If the two features are small enough, we develop them on the same branch. If they're more complex, we will often create a branch that acts like a mini-development branch to create feature branches from and make PRs to. When the interdependent features are ready, we make a PR of this mini-dev branch back to development proper.
Trunk-based development (and adding in dev-environment logic) really misses out on the power of Git. The big advantage of version control is that untested code can be rapidly checked out and used without interfering with reliable code. It ultimately increases effort needed to commit and reduces frequency of commits, since developers need to be very careful not to commit code that doesn't work. Moreover, developers must rely on each other to keep the trunk in working condition. One mistake halts all development. No one can test their own features against known working code with the entire codebase in a state of flux. The larger the project, the greater the risk. Soon enough those daily meetings become week-long workshops that resemble change-board reviews. Eventually quality sacrifices are made just to get it working again due to the building pressure of all the developers waiting on the one problem to be fixed.
Git flow is scalable from an individual to a large organization, and allows concurrent, prioritized development with minimal risk of breaking the trunk. When implemented properly with CI/CD and proper merging permissions, there isn't a quality sacrifice. When WIP PRs are made early and a culture of checking each other's work is promoted, the code remains unified and everyone's concerns are heard.
I respect that trunk-based development has worked for you, and I know it's not always unsuccessful for small projects, but I've seen many trunk-based teams slow to a crawl waiting on individuals and become unable to easily produce working builds on demand because their version control was in their way.
I really disagree. Feature branching is an invaluable aspect of development workflow. I agree that code isn't written in a vacuum and individual developers must be aware of everything else going on simultaneously to avoid disjointed software and the bloat that comes with development each developer trying to be independent.
However, feature branching is not the source of these problems. Poor communication is.
My teams are always checking out each other's feature branches to understand changes being made. WIP pull requests are made as soon as a feature's scaffolding is clear enough to be understood by another developer. Comments are made right away suggesting improvements, warning of pitfalls or inconsistencies, or criticizing the entire approach. As commits roll in, particularly affected parties subscribe to notifications so they can see what's changing and discuss.
When developing, I spend at least 20% of my time in other people's branches, piecing together the way everything will work. When I notice divergence between the branches, I start a lengthy thread on Slack and we figure out how to tighten up our architecture.
What about when developing highly-interdependent features? Keep in mind that they're feature branches, not developer branches, and don't exclude cooperative development by multiple developers on a single branch. If the two features are small enough, we develop them on the same branch. If they're more complex, we will often create a branch that acts like a mini-development branch to create feature branches from and make PRs to. When the interdependent features are ready, we make a PR of this mini-dev branch back to development proper.
Trunk-based development (and adding in dev-environment logic) really misses out on the power of Git. The big advantage of version control is that untested code can be rapidly checked out and used without interfering with reliable code. It ultimately increases effort needed to commit and reduces frequency of commits, since developers need to be very careful not to commit code that doesn't work. Moreover, developers must rely on each other to keep the trunk in working condition. One mistake halts all development. No one can test their own features against known working code with the entire codebase in a state of flux. The larger the project, the greater the risk. Soon enough those daily meetings become week-long workshops that resemble change-board reviews. Eventually quality sacrifices are made just to get it working again due to the building pressure of all the developers waiting on the one problem to be fixed.
Git flow is scalable from an individual to a large organization, and allows concurrent, prioritized development with minimal risk of breaking the trunk. When implemented properly with CI/CD and proper merging permissions, there isn't a quality sacrifice. When WIP PRs are made early and a culture of checking each other's work is promoted, the code remains unified and everyone's concerns are heard.
I respect that trunk-based development has worked for you, and I know it's not always unsuccessful for small projects, but I've seen many trunk-based teams slow to a crawl waiting on individuals and become unable to easily produce working builds on demand because their version control was in their way.
Thanks for writing pretty much the comment I would have written.