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

posted about 3 years ago

CC BY-SA 4.0

Derek Elkins‭

2579 reputation 0 51 253 11

I wouldn't. Not unless you intend to keep developing on every branch independently!

Presumably you're not doing that. In that case, I think it makes your intent clearer to just use a tag to mark the version, then delete the branch. If you ever find that you do need to go back and make some changes that are specific to version 1.2.3.4, you can just create a branch again from that commit tagged 1.2.3.4.

I can't think of a good reason myself to keep the extra branches around. Remember that branches are cheap in Git, it's not like Subversion where it has to copy or delete the entire tree!

Tags and branches are essentially the same thing, they're both just ways of marking a specific commit to make it easier to get back to them later. I think that, in general, it makes it clearer to use tags to represent tree branches that you don't expect to have to do more work on, and actual branches for ones that you do.

Besides which it means your git branch command won't be cluttered up with old versions you don't care about any more.

posted about 3 years ago

CC BY-SA 4.0

Hyperlynx‭

285 reputation 7 5 35 10

You may know me so I am answering :P (someone close to you but you can't find me directly).

Is it a good idea to have a permanent branch for a feature?

Suppose, you have a permanent branch then you had PR 1 years later. Of course, there will be lots of changes in develop branch. But, you forgot to merge them in your branch. Suppose, in that PR you had made changes to line 10 page B. But, in develop branch they had deleted those lines and, they don't need those things anymore. So, your PR is useless. But, if go to merge develop to your branch then your PR then your code will be lost either.

Making the time more shorter : Now, you are going to PR 5 days later. Suppose, the following code was looking like this in your branch.

if(a<b){
   System.out.println(b+" is greater than "+a);
}

You had commited that ^[1]

if(a<b){
   System.out.println(a+" is less than "+b);
}

But, in develop staffs had already done that. Or, removed SOUT and added something else. If you go to merge then your commit will be lost.

If you just commit in page A and, other developers don't touch that page than you can permanently use a branch rather than creating new ones. Cause, it won't affect much more. Most of your commit was on Codegolf.js so, if you want you can use a permanent branch. But, if you want to work on other files then you can use "temporarily" branch.

posted about 3 years ago

CC BY-SA 4.0

Anonymous‭

233 reputation 28 11 7 45