Hello , When implementing a trunk-based development approach with frequent deployments and feature flags, how do you ensure that code changes from different branches don't conflict with each other and cause issues during deployment?

I thought TBD means 0 branches - https://trunkbaseddevelopment.com/#shared-branches-off-mainlinemaintrunk-are-bad-at-any-release-cadence

How about if teams working on complex project choose either branch-per-feature approach or topic branches for smaller changes

Yeah, trunk-based development, in my experience, is almost always working on trunk and using FFlags to eliminate integration, especially for smaller changes. Bigger changes can work on trunk but require as a lot of care (aka energy) and so I do sometimes see bigger feature branches, but then you have to make sure to merge trunk into that branch very often, which has a whole other host of difficulties. In my experience, people then continue to just work the same way (pain in integration) but with the additional overhead of FF. So, uh, you kinda need to pick one, I think? FF is also a lot easier when you have a more service-oriented/modular approach because then someone working on some service somewhere can do a big refactor without impacting someone else...

If it's trunk based, there are no long-lived branches - the research suggests there is a tipping point if you have more than 3 branches, or if the branches live longer than a day. You can use keystoning, where you add code lower down first (so it can go to production, as it's not used) and then add successive layers. Only when you add the keystone (usually the UI, or a public API) do you expose the feature. You could work for a longer period with keystoning without making the feature available and without delaying integration to the main branch.