Menu
They're unnecessary. In most cases, branches, especially branches that were related to a pull request that has since been accepted, serve no purpose. They're clutter. They don't add any significant technical overhead, but they make it more difficult for humans to work with lists of branches in the repository.
There's no problem in deleting branches that have been merged in. All the commits are still available in the history, and even in the GitHub interface, they will still show up (see, e.g., this PR which refers to a fork that I've deleted after the PR got accepted).
I definitely clean up my branches after they've been merged in.
We use GitLab and merge requests at work, so the historical information about branches is stored there; I don't need them cluttering my branch list, and when I look at a coworker's fork, ideally I'd like only to see the branches of their current active development. If I'm trying to look at some code on their branch, I want to be able to look through just a few currently active branches, and not every feature or fix they've ever started work on.
The above applies to BitBucket and GitHub, too.
The only reason you might have for not deleting a branch post-merge is so you know where a given feature ended, but merge commits (and git merge --no-ff if you really want) make that irrelevant.
Just take care of
All hyperlinks URLs references of your DELETED branches, will be BROKEN.
For example
If you delete branch_feature_x branch from your repo
The corresponding hyperlink URL of this branch will be broken
https://github.com/username/project/tree/branch_feature_x
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With