Post History

Your first diagram illustrates a pattern that doesn't really make sense and most likely doesn't reflect what you're actually doing. Specifically, it illustrates a pattern where the feature branch never gets updated from the master/develop branch. I suspect in practice you merge updates from master/develop regularly, or, at the very least, would merge master/develop before the next "iteration" of work on that branch.

Assuming this is the case, there isn't any real difference between the two approaches you suggest except that the "permanent" version ends up with feature branches floating around that no one is working on. To this end, it would seem to make more sense to delete the branches.

One reason I could see someone having a sort of permanent feature branch, which I'm pretty confident is *not* your scenario, was if you wanted to maintain a "baseline" version and a "baseline + feature" version, but in that setup you'd *never* merge the "baseline + feature" version into the "baseline" branch.

At a bit of a deeper level, I feel that you're conflating "marketing" features with "code" features. To give an example to clarify what I mean, a browser vendor might tout bookmarking as a "marketing" feature. This would encompass the entire bookmarking experience. That "marketing" feature, though, would be made up of many "code" features. For example, the ability to bookmark a page could be one "code" feature, another might be the ability to display them in a drop-down, another might be a slide out tab, another might be the ability to sort them various ways. An update to the bookmarking "marketing" feature is either a bug fix or a new (set of) "code" feature(s). A "marketing" feature can be open-ended and evolving, but a "code" feature should be a complete-able thing that is viewed as complete when it is merged into master/develop. It's fine if a "code" feature is changing the behavior of an earlier "code" feature.

Really "feature branch" may not be the best terminology. My impression is that it comes more from the days where there would be a long development cycle before the "feature" could be merged into master. Modern practice is to try to get incremental but functional versions out the door as quickly as possible, gating them behind runtime feature flags if necessary. This allows value and feedback to be gotten from the "feature" much sooner, significantly reduces integration and deployment difficulties and surprises, and let's you stop development as soon as it becomes clear that the remaining "feature points" aren't worth the development effort. An 80-20 rule type situation.