Check out my command-line tool, rotten: <a href="https://github.com/dtrejo/rotten" rel="nofollow">https://github.com/dtrejo/rotten</a><p><pre><code> npm install -g rotten
</code></pre>
It helps you discover<p>* Which remote branches are empty (all code is in master), also outputs a command to delete them all.<p>* Which remote branches still have lots of code that needs to be merged<p>* How long remote branches have been waiting to be merged.<p>.<p>Why is this useful?<p>* discover which projects are languishing<p>* discover which engineers are unhappy that their code is not being reviewed/merged<p>* discover how effective your development process is
To tidy up a repository with lots of merged branches, you can use this script: <a href="http://snippets.freerobby.com/post/491644841/remove-merged-branches-in-git" rel="nofollow">http://snippets.freerobby.com/post/491644841/remove-merged-b...</a><p>Although it seems the best approach would be to actually keep the branch pointers around, but have a way of hiding them to reduce the clutter
On an Enterprise project I was on recently this was a real problem. With about 12 distinct and large (5-10 developers per team) all working on a single git repo, the lingering branches were out of control. They had built up over more than a year of abuse.<p>I think this issue is worth thinking about. For projects with a single owner or a small core set of contributors taking pull requests it is manageable. But when the responsibility is distributed, especially in the degenerate culture of Enterprise Java, uncontrolled branching can make git usage miserable.<p>The real problem was that we were using Git like an SVN server. But it was really interesting to see how bad it can be when branch pruning is not considered upfront.<p>Great feature github :)
Way to go Github! I think it is quite clear that pull requests are the best feature of Github and a boon to the OSS community in general. This feature is a welcome tightening.