3 ms·

This, of course, isn't the only kind of conflict you can have. The delta on a feature branch will almost invariably be larger than the delta on a commit to trun

This, of course, isn't the only kind of conflict you can have. The delta on a feature branch will almost invariably be larger than the delta on a commit to trunk, and if everybody is merging feature branches, even if they are continuously rebased or merged with the trunk, they spend less time being tested in the final merged state and the risk of unexpected feature interactions (not textual conflicts in code) is higher. Trunk based development is better because it forces smaller commits. Everything else flows from that. Smaller commits are easier to test, and have less risk of breaking stuff. Smaller commits are easier to roll back if they break stuff (fewer "unmerge" conflicts, i.e conflicts when you merge the inverse of the patch). Smaller commits force you to develop a better approach to schema and data migrations. Smaller commits force you to add support for feature flags, because a whole feature can't be implemented in a single easily reviewable commit, and now you have tech you can leverage for canaries and so on.

tsimionescu 3y ago
The reality of software development is that any project beyond a handful of devs requires branching. This branching can be achieved in at least two ultimately equivalent ways: - literal branches in your VCS of choice (or forks, clones, etc) - literal runtime branches, via IF on feature flags When a feature is ready to merge to prime time, the branches have to be merged, and unexpected interaction with other features can now be found. This is exactly as likely to happen when doing a git merge as when setting a feature flag to true. Different features working in isolation but interacting badly is a fundamental aspect of software and not some incidental self-caused problem that can be prevented by a better development methodology. To take a somewhat silly example - if one team is working on a feature to make error messages more readable and another team is working on a feature to make error messages opaque IDs looked up in a manual, these two features will obviously clash when they go live regardless of whether they were each behind a feature flag or on separate git branches. Hopefully few organizations would schedule such an obvious conflict of features, but more subtle versions happen all the time.
onion2k 3y ago
Trunk based development is better because it forces smaller commits. There's nothing intrinsic to trunk based dev that forces smaller commits. You'll just have a much worse time if you spend a lot of time making a lot of changes before pushing if you don't do smaller commits.

tsimionescu 3y ago

The reality of software development is that any project beyond a handful of devs requires branching. This branching can be achieved in at least two ultimately equivalent ways: - literal branches in your VCS of choice (or forks, clones, etc) - literal runtime branches, via IF on feature flags When a feature is ready to merge to prime time, the branches have to be merged, and unexpected interaction with other features can now be found. This is exactly as likely to happen when doing a git merge as when setting a feature flag to true. Different features working in isolation but interacting badly is a fundamental aspect of software and not some incidental self-caused problem that can be prevented by a better development methodology. To take a somewhat silly example - if one team is working on a feature to make error messages more readable and another team is working on a feature to make error messages opaque IDs looked up in a manual, these two features will obviously clash when they go live regardless of whether they were each behind a feature flag or on separate git branches. Hopefully few organizations would schedule such an obvious conflict of features, but more subtle versions happen all the time.

onion2k 3y ago

Trunk based development is better because it forces smaller commits. There's nothing intrinsic to trunk based dev that forces smaller commits. You'll just have a much worse time if you spend a lot of time making a lot of changes before pushing if you don't do smaller commits.