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!

  • 1
    see Where does my git question go?
    – gnat
    Jul 12, 2017 at 19:11
  • I'm seeing one problem with using git branch -r --merged when I have a remote for everyone's fork and that is that if a branch name doesn't appear for some forks I cannot tell whether that means they don't have the branch at all or they do and they have unmerged commits on that branch...
    – Hugh
    Jul 12, 2017 at 19:20
  • This looks to me like something that has to be discussed in your team. It doesn't matter what you do as long as everyone knows that it is happening and why it is happening. We cannot provide a magical formula that works best in every case
    – BlueWizard
    Jul 15, 2017 at 22:01

1 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.

  • So if branch project_x in the upstream has been merged at some point to master, then yes its safe to delete the branch. If a developer's fork branch project_x has additional commits then yes they will be safe but by deleting the principal branch they will get an error locally if they had been tracking that project_x branch on the upstream. I should add that our workflow doesn't allow arbitrary developers to create branches on the upstream, we (team leads) create these as needed by projects etc when we think > 1 developer will work on it.
    – Hugh
    Jul 12, 2017 at 22:01
  • Also we should ensure there are no pending pull requests targeting some branch before we delete it too.
    – Hugh
    Jul 12, 2017 at 22:16
  • @Hugh They'll only get an error if they try to pull the branch you deleted. But that's okay because the pull wasn't going to achieve anything anyway because there were no new commits.
    – user253751
    Jul 25, 2017 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.