How long is it appropriate to keep old feature branches in git?

Question

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.

Answer 1

Feature branches should stay until the feature is done, once done the branch must be closed/deleted. Establishing this kind of behavior should 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 makes maintainability harder. You might think 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 distinguish them, but that's not the case once you have a dozen of them and even more are constantly piling 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.

Answer 2

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.

Answer 3

Re „How long should feature branches last?“

Just as short as possible. Just as long as needed. "Old feature branch" is a contradiction in itself.

We use Scrum with JIRA as ticketing tool. No feature branch lasts more than the 2 weeks sprint period, ever. Our tickets' planned times go from, often, 2 (net working) hour to, almost never, 40 (net working) hours (that's 2 weeks at 50 % net developing time).

Set Blocked by in a task if advised. Tasks with no blocker can be done in parallel, by different persons. With such a fine-granular process any dev can easily continue on a ticket (in case of a day-off, sick leave, burndown of an office at another location, etc.) or begin to work on a new one without having to care about prerequisites.

If a task's estimated fulfilment time tends to be longer than two days, it's splitted into smaller tasks.

Example: Project using Java, JUnit, GitLab, Eclipse, Maven, Jenkins

Dev Tasks

• Create Jenkins projects for the branches main, develop, feature, hotfix, release
• Create Git repo(s) (including configuring access right etc.)
• Create Maven project(s) (from within Eclipse), adapt POM declarations accordingly (properties, dependencies, plugins, ...)
• Implement the framework: create packages, interfaces, test classes and classes/enums with empty methods, resources and test resources for a start (this task can also be split into more than one depending on the size of the project)
• Implement functionality (can be split depending on...see above)

Git tasks (for each of the dev tasks above)

• If a ticket's status changes from New to In implementation a feature branch is created.
• If a ticket's status changes from In implementation to Implemented a review is done.
• If a ticket's status changes from Implemented to Closed the feature branch is merged and deleted.

---

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

See SO for git gc.

In a git flow initialized repo there are basically two of them:

• git flow feature start <name> [<base>]
• git flow feature finish [<name>]

(main) $ git flow init
... 6 times <Enter> to accept the defaults ...
(develop) $ git branch
* develop
  main
$ git flow feature start my-cool-feature
Switched to a new branch 'feature/my-cool-feature'

Summary of actions:
- A new branch 'feature/my-cool-feature' was created, based on 'develop'
- You are now on branch 'feature/my-cool-feature'

Now, start committing on your feature. When done, use:

     git flow feature finish my-cool-feature

(feature/my-cool-feature) $ git branch
  develop
* feature/my-cool-feature
  main
...
(feature/my-cool-feature) $ git status | add | commit | pull | push | gc | ...  # whatever
...
(feature/my-cool-feature) $ git flow feature finish  # without a feature name it finishes the current
Switched to branch 'develop'
Already up to date.
Deleted branch feature/my-cool-feature (was a57868f).

Summary of actions:
- The feature branch 'feature/my-cool-feature' was merged into 'develop'
- Feature branch 'feature/my-cool-feature' has been locally deleted
- You are now on branch 'develop'

(develop) $ git push  # if there's a remote repo
(develop) $ git branch
 1. develop
  main
(develop) $ git flow feature start my-even-cooler-feature
...
(feature/my-even-cooler-feature) $

Long story short from the bottom of the page Gitflow Workflow:

The overall flow of Gitflow is:

1. A develop branch is created from master [now main]
2. A release branch is created from develop
3. Feature branches are created from develop
4. When a feature is complete it is merged into the develop branch
5. When the release branch is done it is merged into develop and master [or main]
6. If an issue in master is detected a hotfix branch is created from master
7. Once the hotfix is complete it is merged to both develop and master [or main]