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.
Comments on Is it a good idea to have a permanent branch for a feature?
Parent
Is it a good idea to have a permanent branch for a feature?
I'm rather new to using git, so I'm not sure about the best practices regarding it. I have a feature branch branched off, and periodically when the feature needs to be updated I will add some commits to the branch and then create a pull request.[1]
Is it a good idea to have a permanent branch for this feature, or should I delete it after merging and create a new branch whenever an issue comes up? Right now I'm doing the former, but I've also heard that branches should have a single purpose so I'm not sure if it's actually a good idea.
Basically, should I do
-
Update feature branch -> Merge -> Update feature branch -> Merge
---O--O---O--O----O--- \__\_/____\__/____
or
-
Create feature branch -> Merge and delete branch -> Create new branch -> Merge and delete branch
---O--O---O-O-----O--- \__\_/ \___/
-
It's for the Code Golf leaderboard, if you were wondering. ↩︎
Post
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.
0 comment threads