Usually, feature branches mean that all the work to implement a particular feature is done on that branch. That could be dozens of commits and weeks of work from several developers. The code isn't merged until the feature is complete. It's more common in the industry compared to trunk-based development.

My previous employer had:

• Feature branches for each new feature.
• A dev/trunk branch, where features branches were merged once they were done.
• A beta branch, branched from dev once per week.
• A live/prod branch, branched from beta four times per year.

This structure is very common in enterprise apps. Customers that need stability (don't want things to change a lot, for example if they have their own training material for their staff) use the live branch, while customers that want the newest features use the beta branch.

Bug fixes were annoying since you'd have to first do them in the live branch then port them to the beta and dev branches (or vice versa).

On the other hand, feature flags mean that all the code goes directly into the trunk branch, but it's turned off until it's ready. A basic implementation of feature flags would be a static class with a bunch of booleans that get checked throughout the code, but they're usually dynamic so a misbehaving feature can be turned off without having to redeploy the code.

Some codebases use both feature branches and feature flags.