2

I am on a large team with many developers. We have a large codebase that has many feature branches from our large group of developers. We are accumulating many feature branches.

We generally look to git-flow for best practices.

How long should feature branches last?

Is it safe enough and not costly or degrading to performance to keep all of them?

Are there considerations and maintenance commands that developers need to execute every so often to have working, efficient, and responsive git ?

Thanks.

  • 1
    Not really git, but I've had lots of trouble with Jenkins falling over because of too many feature branches. Your question provokes quite subjective answers, I think. – Bruce Becker Apr 3 at 20:04
3

Feature branches schould stay until the feature is done, once done the branch must be closed/deleted. Establishing this kind of behavior schould be a team goal and usually takes some time, it's just easier to forget about them in the hurry up I'm ready with my pull request mode.

Keeping all of them is a maintaining hell. You might be thinking that each branch follows a naming convention with a map to a JIRA ticket or whatever kind of mapping you have and it's really straight forward to make a distinguishment, but that's not the case once you have a dozen of them and even more are constantly pocking up. I highly doubt performance has anything to do, it's more like a confusion cost switch.

Regarding the commands, I do not think so.

| improve this answer | |
0

I agree with Recoba20's answer and I just want to add a couple of things.

We generally look to git-flow for best practices.

This means that

  1. at some point you also merge those branches into the mainline (the master branch).
  2. you are merging with the --no-ff flag

If this is the case, then actually keeping the branches doesn't help your process in any way, I think. The changes are already in, and if you need a bug fix or a change, that means you will start a new branch from further down the line, and not from the original feature branch (according to git-flow).

One thing that I can see happening is somehow messing up the mainline (or release-X), and you need to recreate a set of features brought together. If you already have the branches, i.e. not deleted, you can create a new release branch and merge the correct features back in. If you don't have the branches, that's not that big an issue, because by using --no-ff merges, there is a separate commit for when a branch is being merged in. And, as branches are just pointers to commits, you can just create a branch at that particular last commit, and it's just as you have never deleted it in the first place.

Is it safe enough and not costly or degrading to performance to keep all of them?

I'm not sure git itself would have problems with this, given that branches are just refs (a pointer to a commit), but at the same time it wouldn't surprise me for things to be slow in some cases, e.g. cloneing.

One issue that I can see happening more likely is performance degradation of some git GUIs. For which I'd recommend some lightweight ones; I've used gitk for a long time and it's just right for having a quick overview of the commit tree.

Are there [...] maintenance commands that developers need to execute every so often to have working, efficient, and responsive git ?

I would just mention git branch --no-merged master for getting a list of branches not merged yet. It doesn't fix anything, but gives a visual of what you're working with.


Having said that, I suggest you think about your development process more, and consider doing things a bit different. In my experience, most git problems are just symptoms of a process that's not quite tweaked for the intentions. git is just there and taking the hits. Having long running (days, weeks) feature branches makes it more likely to run into issues when integrating back.

An alternative to this is to merge more often and/or to use feature toggles.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.