# Best practice of deleting branches on Github
**URL:** https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712
**Category:** Offtopic
**Tags:** question
**Created:** [March 8, 2025, 1:09pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712 "2025-03-08T13:09:22Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 8, 2025, 1:09pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/1 "2025-03-08T13:09:22Z")
We are currently actively developing a package and create a few new branches (pull requests) per day.
When would you delete these branches? Immediately after merging the pull request, or rather later?
And how can I delete a remote branch in the first place?
---
### Author:  [@Ahmed\_Salih](https://discourse.julialang.org/u/Ahmed_Salih)
#### Post date: [March 8, 2025, 1:18pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/2 "2025-03-08T13:18:55Z")
I would flip the question. Why would you keep branches which has already been merged in?
While it can make sense to keep old branches for a while, after some time the main branch has deviated so much, that the knowledge held in the older branches (which have already been merged in!) is not that useful.
I, personally, would recommend to not keep older PR branches around, since I have rarely found it useful.
Would be interesting to hear what others think.
Kind regards
---
### Author:  [@ericphanson](https://discourse.julialang.org/u/ericphanson)
#### Post date: [March 8, 2025, 1:35pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/3 "2025-03-08T13:35:32Z")
You can configure GitHub repos to auto-delete the remote branch when a PR is merged, and I think you can configure git to delete tracking branches locally when that happens ([How Core Git Developers Configure Git](https://blog.gitbutler.com/how-git-core-devs-configure-git/))
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 8, 2025, 1:53pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/4 "2025-03-08T13:53:38Z")
> [@Ahmed\_Salih](#):
>
> I would flip the question. Why would you keep branches which has already been merged in?
Well, I usually sqash the branch of a pull request before merging it. But sometimes a bug squeezed in, and then it is useful to undo just the one commit that caused the bug.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [March 8, 2025, 3:04pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/5 "2025-03-08T15:04:15Z")
> [@ufechner7](#):
>
> Well, I usually sqash the branch of a pull request before merging it. But sometimes a bug squeezed in, and then it is useful to undo just the one commit that caused the bug.
If really needed you can restore a branch after it has been deleted using GitHub UI.
One big reason for deleting all branches of merged and closed PRs is that when cloning a repository _all_ branches are fetched, fetching branches that aren’t going to be used for literally anything is a big waste of everybody’s bandwidth.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 8, 2025, 3:23pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/6 "2025-03-08T15:23:19Z")
I did not know that you can restore a deleted branch. How is Github doing that?
Any way, knowing that this is possible I will now always delete my branches after merging.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [March 8, 2025, 3:29pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/7 "2025-03-08T15:29:53Z")
> [@ufechner7](#):
>
> How is Github doing that?
GitHub never deletes any content ever pushed to it. Which makes restoring “deleted” branches possible.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [March 8, 2025, 4:41pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/8 "2025-03-08T16:41:22Z")
> [@giordano](#):
>
> GitHub never deletes any content ever pushed to it. Which makes restoring “deleted” branches possible.
- Are you sure restoring a branch will always be possible? Perhaps Github does some garbage collection for very old branches?
- One thing I know is that deleting the fork prevents restoring the branch. I can see that in some of my old PRs.
- In any case, I think it’s possible to access a merged PR’s commits even if the original branch is deleted: [Checking out pull requests locally - GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally)
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [March 8, 2025, 4:49pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/9 "2025-03-08T16:49:40Z")
> [@nsajko](#):
>
> Are you sure restoring a branch will always be possible? Perhaps Github does some garbage collection for very old branches?
They don’t officially promise not to garbage-collect, but it’s pretty well-established that GitHub never ever deletes anything. It would mess majorly with their entire infrastructure if they changed that. So it’s a pretty safe assumption.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [March 8, 2025, 4:49pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/10 "2025-03-08T16:49:52Z")
> [@nsajko](#):
>
> Are you sure restoring a branch will always be possible?
Well, I can’t speak for future GitHub’s plans, but that’s what it is now.
> [@nsajko](#):
>
> Perhaps Github does some garbage collection for very old branches?
They don’t do that. In the backend GitHub doesn’t have a standard git repo, but a rather sophisticated “database” which can interact with standard git clients.
> [@nsajko](#):
>
> One thing I know is that deleting the fork prevents restoring the branch. I can see that in some of my old PRs.
You should still be able to fetch the ref of a PR.
---
### Author:  [@bertschi](https://discourse.julialang.org/u/bertschi)
#### Post date: [March 8, 2025, 5:05pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/11 "2025-03-08T17:05:05Z")
There seem to be some misconceptions on what a branch is. As far as I understand, a branch has no internal meaning to git. Instead it is just a convenient way to (temporary) name a particular stream of commits (see [here](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) for details). I.e., as also explained in this stackoverflow [post](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) deleting a branch just deletes the corresponding file in `.git/refs/heads/` which only content was a git hash referring to the commit currently named ``.
Thus, you can always delete and restore branches (from any commit) at will. Internally, git only cares about commits and deleting those is more complicated and requires rewriting the git history.
---
### Author:  [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)
#### Post date: [March 8, 2025, 9:07pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/12 "2025-03-08T21:07:45Z")
Sorry but I have to nitpick your post, there are dangerous statements there.
- It’s true that a branch is only a pointer to a commit.
- It’s true that deleted branches can be recreated from the last commit in that branch - _provided that the commit still exists._
- When you delete a branch, any commits that were unique to that branch become “unreachable”, and are only accessible by commit hash/id (which can be found in the reflog for [30 days, by default](https://www.kernel.org/pub/software/scm/git/docs/git-gc.html)).
- Unreachable commits (i.e. not tagged or in a branch) more than 30 days old _are permanently deleted when git performs garbage collection_.
- Garbage collection can be triggered by [common git operations](https://stackoverflow.com/questions/28246216/git-when-does-git-perform-garbage-collection) such as fetch and merge when there are too many [“loose objects”](https://stackoverflow.com/questions/5709687/what-are-the-loose-objects-that-the-git-gui-refers-to).
- So branches cannot “always” be restored at will - only for 30 days, or if the commits exist in ancestor trees of other branches and tags.
- Deleting commits isn’t complicated. Delete all branches they occur in and they’ll be gone in the next garbage collection after 30 days.
- A git rebase is often called “rewriting history”, but it doesn’t actually rewrite anything. It creates new commits and makes the old ones unreachable, but you can still find them in the reflog (for 30 days).
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 8, 2025, 9:46pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/13 "2025-03-08T21:46:32Z")
> [@NiclasMattsson](#):
>
> When you delete a branch, any commits that were unique to that branch become “unreachable”, and are only accessible by commit hash/id (which can be found in the reflog for [30 days, by default](https://www.kernel.org/pub/software/scm/git/docs/git-gc.html)).
But is this true on Github, assuming Github is not a normal git server but uses some other way of storing the commits?
---
### Author:  [@bertschi](https://discourse.julialang.org/u/bertschi)
#### Post date: [March 8, 2025, 11:06pm UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/14 "2025-03-08T23:06:59Z")
Thanks for clarifying that branches still matter as references to commits, i.e., in order to render them reachable. Yet, in the end it’s the structure of commits that matters and a commit from a merged branch (as in the OP) stays reachable even after deleting its branch, i.e., name. Also “delete all branches they occur in” might not be easy to do (or imply deleting main and most of the repo) when the commit is part of a long merged history. In this case, it must probably be made unreachable explicitly by creating essentially a new chain of commits around it, e.g., via git rebase.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [March 9, 2025, 3:47am UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/15 "2025-03-09T03:47:22Z")
> [@ufechner7](#):
>
> But is this true on Github
No.
---
### Author:  [@hexaeder](https://discourse.julialang.org/u/hexaeder)
#### Post date: [March 9, 2025, 5:45am UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/16 "2025-03-09T05:45:16Z")
> and a commit from a merged branch (as in the OP) stays reachable even after deleting its branch,
The OP specifically said they are squash merging. Are the commits of squashed pr considered ancestors of the merge commit? I always assumed squash merge means to „copy“ the pr, sqash history and merge a single squashed commit. Or is squash merging something more clever?
---
### Author:  [@bertschi](https://discourse.julialang.org/u/bertschi)
#### Post date: [March 9, 2025, 9:17am UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/17 "2025-03-09T09:17:09Z")
Sorry had missed that part. Guess you are right, squashing simply creates a new commit and leaves the old ones dangling.
Should stop commenting on that thread. At least for me the discussion has cleared some things up, though.
---
### Author:  [@tecosaur](https://discourse.julialang.org/u/tecosaur)
#### Post date: [March 10, 2025, 6:53am UTC](https://discourse.julialang.org/t/best-practice-of-deleting-branches-on-github/126712/18 "2025-03-10T06:53:21Z")
To me this sounds more like an argument against squash merging more than anything else 🙃