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
- at some point you also merge those branches into the mainline (the
- you are merging with the
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.
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.