Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-04-03T20:09:40.317Z
Answers: 2020-12-04T10:53:11.323Z
Answers: 2020-12-04T10:53:11.323Z
Answers: Recoba20
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-16T00:27:45.727Z
Answers: Thanks for mentioning `--no-merged`, TIL.
Answers: jalanb
Answers: CC BY-SA 4.0
Answers: 2020-05-28T08:50:28.157Z
Answers: 2020-05-28T08:50:28.157Z
Answers: Andrei Mustață
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-12-04T04:11:53.617Z
Answers: 2020-12-04T18:51:14.927Z
Answers: 2020-12-04T18:51:14.927Z
Answers: Gerold Broser
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2020-04-03T20:04:36.077Z
Comments: 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.
Comments: Bruce Becker
Tags: <git>
Title: How long is it appropriate to keep old feature branches in git?
UserDisplayName: David West
ThreadText: # 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`](https://stackoverflow.com/q/2116778/1744774).
  
  In a [`git flow init`ialized repo](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) there are basically two of them:
  
  * `git flow feature start <name> [<base>]`
  * `git flow feature finish [<name>]`
  
  ```bash
  (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](https://www.atlassian.com/git/tutorials/comparing-workflows/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`]
  
  
  ---
  
  