<p>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.</p>
<p>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.</p>
<p>Regarding the commands, I do not think so.</p>

CC BY-SA 4.0
2020-04-03T20:09:40.317Z
2020-12-04T10:53:11.323Z
2020-12-04T10:53:11.323Z
Recoba20
<p>I agree with <a href="https://devops.stackexchange.com/a/11233/22454">Recoba20's answer</a> and I just want to add a couple of things.</p>

<blockquote>
  <p>We generally look to git-flow for best practices.</p>
</blockquote>

<p>This means that </p>

<ol>
<li>at some point you also merge those branches into the mainline (the <code>master</code> branch).</li>
<li>you are merging with the <a href="https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---no-ff" rel="nofollow noreferrer"><code>--no-ff</code> flag</a></li>
</ol>

<p>If this is the case, then actually keeping the branches doesn't help your process in any way, <em>I think</em>. 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).</p>

<p>One thing that I can see happening is somehow messing up the mainline (or <code>release-X</code>), 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 <code>--no-ff</code> 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.</p>

<blockquote>
  <p>Is it safe enough and not costly or degrading to performance to keep all of them?</p>
</blockquote>

<p>I'm not sure <code>git</code> 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. <code>clone</code>ing.</p>

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

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

<p>I would just mention <a href="https://git-scm.com/docs/git-branch#Documentation/git-branch.txt---no-mergedltcommitgt" rel="nofollow noreferrer"><code>git branch --no-merged master</code></a> for getting a list of branches not merged yet. It doesn't <em>fix</em> anything, but gives a visual of what you're working with.</p>

<hr>

<p>Having said that, I suggest you think about your development process more, and consider doing things a bit different. In my experience, most <code>git</code> problems are just symptoms of a process that's not quite tweaked for the intentions. <code>git</code> 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.</p>

<p>An alternative to this is to merge more often and/or to use <a href="https://martinfowler.com/bliki/FeatureToggle.html" rel="nofollow noreferrer">feature toggles</a>.</p>

CC BY-SA 4.0
2021-01-16T00:27:45.727Z
Thanks for mentioning `--no-merged`, TIL.
jalanb
CC BY-SA 4.0
2020-05-28T08:50:28.157Z
2020-05-28T08:50:28.157Z
Andrei Mustață
<p>Re „<em>How long should feature branches last?</em>“</p>
<p>Just as short as possible. Just as long as needed. &quot;Old feature branch&quot; is a contradiction in itself.</p>
<p>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).</p>
<p>Set <em>Blocked by</em> 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.</p>
<p>If a task's estimated fulfilment time tends to be longer than two days, it's splitted into smaller tasks.</p>
<h3>Example: Project using Java, JUnit, GitLab, Eclipse, Maven, Jenkins</h3>
<p><strong>Dev Tasks</strong></p>
<ul>
<li>Create Jenkins projects for the branches main, develop, feature, hotfix, release</li>
<li>Create Git repo(s) (including configuring access right etc.)</li>
<li>Create Maven project(s) (from within Eclipse), adapt POM declarations accordingly (properties, dependencies, plugins, ...)</li>
<li>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)</li>
<li>Implement functionality (can be split depending on...see above)</li>
</ul>
<p><strong>Git tasks (for each of the dev tasks above)</strong></p>
<ul>
<li>If a ticket's status changes from <em>New</em> to <em>In implementation</em> a feature branch is created.</li>
<li>If a ticket's status changes from <em>In implementation</em> to <em>Implemented</em> a review is done.</li>
<li>If a ticket's status changes from <em>Implemented</em> to <em>Closed</em> the feature branch is merged and deleted.</li>
</ul>
<hr />
<p>Re „<em>Are there considerations and maintenance commands that developers need to execute every so often to have working, efficient, and responsive git ?</em>“</p>
<p>See <a href="https://stackoverflow.com/q/2116778/1744774">SO for <code>git gc</code></a>.</p>
<p>In a <a href="https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow" rel="nofollow noreferrer"><code>git flow init</code>ialized repo</a> there are basically two of them:</p>
<ul>
<li><code>git flow feature start &lt;name&gt; [&lt;base&gt;]</code></li>
<li><code>git flow feature finish [&lt;name&gt;]</code></li>
</ul>
<pre class="lang-bash prettyprint-override"><code>(main) $ git flow init
... 6 times &lt;Enter&gt; 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) $
</code></pre>
<p>Long story short from the bottom of the page <a href="https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow" rel="nofollow noreferrer">Gitflow Workflow</a>:</p>
<blockquote>
<p>The overall flow of Gitflow is:</p>
<ol>
<li>A <code>develop</code> branch is created from <code>master</code> [now <code>main</code>]</li>
<li>A <code>release</code> branch is created from <code>develop</code></li>
<li><code>Feature</code> branches are created from <code>develop</code></li>
<li>When a <code>feature</code> is complete it is merged into the <code>develop</code> branch</li>
<li>When the release branch is done it is merged into <code>develop</code> and <code>master</code> [or <code>main</code>]</li>
<li>If an issue in <code>master</code> is detected a <code>hotfix</code> branch is created from <code>master</code></li>
<li>Once the <code>hotfix</code> is complete it is merged to both <code>develop</code> and <code>master</code> [or <code>main</code>]</li>
</ol>
</blockquote>

CC BY-SA 4.0
2020-12-04T04:11:53.617Z
2020-12-04T18:51:14.927Z
2020-12-04T18:51:14.927Z
Gerold Broser
<p>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.</p>

<p>We generally look to git-flow for best practices.</p>

<p>How long should feature branches last?</p>

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

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

<p>Thanks.</p>

CC BY-SA 4.0
2020-04-03T20:04:36.077Z
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
<git>
How long is it appropriate to keep old feature branches in git?
David West
# How long is it appropriate to keep old feature branches in git?

(Asked by: username_0 on 2020-04-03)

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.

**Tags:** git

> **Comments:**
> **username_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.  

---

## 3 answers

### Answer by username_2 on 2020-04-03. Score: 7

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 by username_3 on 2020-05-28. Score: 2

I agree with [username_2's answer](https://devops.stackexchange.com/a/11233/22454) 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](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---no-ff)

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. `clone`ing.

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`](https://git-scm.com/docs/git-branch#Documentation/git-branch.txt---no-mergedltcommitgt) 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](https://martinfowler.com/bliki/FeatureToggle.html).

> **Comments:**
> **username_4**: Thanks for mentioning `--no-merged`, TIL.  

---

### Answer by username_5 on 2020-12-04. Score: 0

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  []
git flow feature finish []

(main) $ git flow init
... 6 times  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:

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


---

