
Tidying up after Pull Requests - janerik
https://github.com/blog/1335-tidying-up-after-pull-requests
======
DTrejo
Check out my command-line tool, rotten: <https://github.com/dtrejo/rotten>

    
    
        npm install -g rotten
    

It helps you discover

* Which remote branches are empty (all code is in master), also outputs a command to delete them all.

* Which remote branches still have lots of code that needs to be merged

* How long remote branches have been waiting to be merged.

.

Why is this useful?

* discover which projects are languishing

* discover which engineers are unhappy that their code is not being reviewed/merged

* discover how effective your development process is

~~~
fmstephe
That is a great looking tool

As a suggestion, I think you should include the list of features you wrote in
this thread in your readme. That list made me really want to try out the tool.
If I had only read your readme on github I would not have been as interested.

~~~
DTrejo
Just updated the readme; thanks for the suggestion :)

~~~
fmstephe
Cheers for that. I passed the github link and your list of features to the
guys I used to work with on the Enterprise project I mention below. If it
solves any pain I'll try to let you know :)

------
jordanthoms
To tidy up a repository with lots of merged branches, you can use this script:
[http://snippets.freerobby.com/post/491644841/remove-
merged-b...](http://snippets.freerobby.com/post/491644841/remove-merged-
branches-in-git)

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

~~~
jevinskie
Some sort of "don't show if last used in > x days" would be handy to have in
git (CLI) and gitk.

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

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.

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.

Great feature github :)

~~~
judofyr
Did you consider using forks more actively? E.g. each team has it's own fork
where they commit, and one person is responsible for merging the fork
upstream?

~~~
snprbob86
I second this. We really enjoyed the one fork per user model. Each fork's
owner was responsible for their own branches, which was much more manageable.

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

------
guynamedloren
Biggest pain point associated with code reviews are the lingering branches. So
glad this has finally been bundled into Github. Thanks Github!

------
unwiredben
Excellent... I've been manually sweeping for these about once a month on Enyo,
but it will be nice to have it part of our merge flow.

~~~
nicolasv
Bitbucket asks the question about whether to close the branch in a pull
request at the time you create it, e.g.,

    
    
      https://s3.amazonaws.com/uploads.hipchat.com/10804/29957/csa3g3hjsk6i27p/close-branch-after-merge.png
    

since the person creating it is usually in the best position to decide whether
the feature branch they're working on is "complete".

Though I really like GitHub's implementation for cleaning up old pull requests
(or ones you forgot to tick the close branch checkbox for).

(Full disclosure: I'm a developer on Bitbucket for Atlassian.)

~~~
voltagex_
Thank you for BitBucket! If you ever need a C# dev, let me know ;)

------
meastham
It always baffled me that this feature didn't exist before. I'm glad they
implemented it.

------
dochtman
So when I merge a pull request on Github, it's rebased, not actually merged?

~~~
zalambar
What makes you think that is the case? It looks equivalent to a "git merge
--no-ff <feature-branch>" to me. The feature branch is then merged with master
(or whatever the target branch was) and would appear if you ran "git branch
[-r] --merged" from the target branch which is a good hint that it can be
safely deleted.

------
cmaggard
I've been waiting for this for quite some time now. Kudos!

