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

Dashboard
Notifications
Mark all as read
Q&A

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

+6
−0

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---
        \__\_/   \___/
    

  1. It's for the Code Golf leaderboard, if you were wondering. ↩︎

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

3 answers

+5
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

I regularly pull from the main branch (2 comments)
+2
−0

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.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+0
−1

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.


  1. I know both context represent same thing. I am just giving an example. ↩︎

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

That's about the weirdest -- and slightly creepy -- intro to an answer i have ever seen on any Q&A site... (1 comment)

Sign up to answer this question »