Tidying up after Pull Requests

https://github.com/blog/1335-tidying-up-after-pull-requests

by janerik • 14 years ago

105 19 14 years ago

unwiredben• 14 years ago

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• 14 years ago

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_• 14 years ago

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

meastham• 14 years ago

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

cmaggard• 14 years ago

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

guynamedloren• 14 years ago

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

fmstephe3• 14 years ago

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• 14 years ago

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• 14 years ago

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.

tux1968• 14 years ago

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.

DTrejo2• 14 years ago

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

fmstephe3• 14 years ago

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.

DTrejo2• 14 years ago

Just updated the readme; thanks for the suggestion :)

jordanthoms• 14 years ago

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

jevinskie• 14 years ago

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

STRML• 14 years ago

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.

dochtman• 14 years ago

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

zalambar• 14 years ago

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.

Tidying up after Pull Requests

Related Stories