How to robustly identify obsolete Git branches

Question

We use Github and Smartgit.

We are often finding we have lots of "old" branches that clutter up our repos and cause confusion among our Dev team, I can use: git branch --merged for a lot of this.

So I'm seeking to define the rules for safely deleting a branch from an upstream repo, here (in English) is my suggested "algorithm":

Identify candidate branches by running:

git branch -r --merged

For each listed branch on our main/upstream repo
    For each fork of the repo
        If there is no fork that has additional commits on the branch Then
           If there is no local repo that has additional commits on the branch Then
              Delete the branch.

Admittedly this can't be automated (because of the local repos) but I want to establish if these rules are sound and sufficient for safely deleting.

If so I can document and have all developers made aware of the overall algorithm.

Next question, if the above is sound is there any tool we can run that can automatically check every fork? Or must I (in an admin capacity) create a remote for everyone's fork so that I can see all of these when I run the command with the -r option?

I would imagine that this could be a GREAT feature for Github to provide because they know about all of the forks.

It wouldn't be a great thing perhaps for popular open source repos, but for private companies with just a handful of (per developer) forks it could be extremely useful.

Comments, suggestions appreciated!

Answer 1

You're way overthinking this. In git, all branches from all repos are created equal. It's completely safe to delete any branch that has been merged into another branch. If someone has additional commits on top of that branch somewhere else that you don't know about, they can always recreate that branch at any time from their own copy. Just look for branches that haven't had commits in a while.

This even works for unmerged branches. If someone created an unmerged branch a long time ago then abandoned it, send out an email saying they have a week to pull it before it gets deleted. If they pick up that work later, they can always recreate that branch from their own copy. Maybe create an "archive" repo instead of deleting outright if you're really paranoid about losing code.

The best policy, though, is just to get in the habit of deleting branches right after merging the pull requests.