Tidying up after Pull Requests | Hacker News Reader

Tidying up after Pull Requests

github.com

105 pointsjanerik19 comments

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

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.

Just updated the readme; thanks for the suggestion :)

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 :)

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

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

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

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 :)

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?

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.

That's really the way Git was designed to be used. Trying to use Git in an SVN model is doable, but suboptimal and likely to lead to the types of issues the parent comment was complaining about.

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.

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

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.

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

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

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

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

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.

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

Reply on news.ycombinator.com