Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

77%
+5 −0
Q&A Is it a good idea to have a permanent branch for a feature?

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 n...

posted 2y ago by Derek Elkins‭

Answer
#1: Initial revision by user avatar Derek Elkins‭ · 2021-08-30T04:03:35Z (over 2 years ago)
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.