Here’s my implementation (note that I’m neither a git expert nor a shell scripting expert):

1. Determine the set of branches that, when another branch has been merged into it, make up the modified meaning of a branch having been merged
2. Determine a pattern that narrows the list of all branches to only the branches in the previous set. For me, it was origin/release
3. Do everything else:

git branch --remote --list origin/release/* --format="%(objectname)" | xargs -n1 -I {} git branch --remote --merged {}

What use is this?

Git has functionality to determine which branches are already merged into a specified branch (see git branch documentation and the git branch --merged flag in particular). This works well if you’re looking at a single branch at a time. The product I work on during the day has many developers working on multiple different releases at any one time – usually ~5 versions of the product are deployed and covered by service level agreements that ensure they’re continually supported. This is the reality for a great many enterprise applications deployed on customer infrastructure – continuous deployment just isn’t a thing without massive investment from all involved.

I found that developers were not good at cleaning up feature branches after they’ve merged them into their respective release stream. As a first step, I wanted to understand how many branches were actually merged, where “merged” is defined as “merged into any of the various release branches”. I’m suspicious that git has this functionality somewhere, but I wasn’t able to find it.