When to delete branches in Git?

You can safely remove a branch with git branch -d yourbranch. If it contains unmerged changes (ie, you would lose commits by deleting the branch), git will tell you and won't delete it.

So, deleting a merged branch is cheap and won't make you lose any history.

To delete a remote branch, use git push origin :mybranch, assuming your remote name is origin and the remote branch you want do delete is named mybranch.

What you need to do is tag anything that you release. Keep branches around for when you are actively developing.

Delete old branches with

git branch -d branch_name

Delete them from the server with

git push origin --delete branch_name

or the old syntax

git push origin :branch_name

which reads as "push nothing into branch_name at origin".

That said, as long as the DAG (directed acyclic graph) can point to it, the commits will be there in history.

Google "git-flow" and that may give some more insight on release management, branching and tagging.

Since the question has the "github" tag, I'd also add this: specifically in Github, if you pull-request a branch and it gets merged (either via the UI or by merging the pull request's branch), you won't lose the pull request data (including comments), even if you remove the branch.

A consequence of this: If you incorporate pull requests as a part of your workflow (which blends sweetly with code reviews), you can safely delete branches as soon as they get merged. This is so commonplace that recently Github added a (sweet) feature that pops a "delete branch" button right after you merge a pull request.

But it is worth noticing that each group should adopt the workflow that suits it best (and it may or may not lead to deleting such branches). My current work team, for example, prunes all branches that are not master or deployment-related (e.g., production, staging, etc.) as soon as their pull requests gets merged, and we still have full tracking of how the related commits formed each incremental improvement of each product.

Of course no history management (pull requests or otherwise) replaces proper tagging of versions (which you preferably automate with the same tool/script that deploys/packages a version), so you can always fast-switch to whatever your users happen to be on at a given moment. Tagging is also the key to solve your original problem: if you establish that any branch merged to the "work" branches can and should be deleted, and that any one that is merged to a version tag, "production", etc. should not, you'll always have the hotfixes alive until they are integrated in a future version.