We recently shipped a new About section. It has all sorts of stuff like
high resolution logos, pictures of the GitHub team, a little bit about our story, recent press mentions and maybe most importantly positions
we’re hiring for. It’s awesome.
But that’s not the point of this post. Instead, let’s take
a look at how we used a massive Pull Request to ship this feature.
Here is what the PR looked like for the new
You’re looking at 130 commits and 91 comments from 10 different people over a two
month timespan. The discussion ranged from the original idea and HTML mock-up, to
Skitch mock ups from developers, to content strategy. There are designs posted
for review at various points. And of course, every commit to the branch is
tracked and ready for code review.
If you’ve ever talked to a GitHubber you’ll know we think Pull Requests are the
greatest thing ever. And not just because we invented them.
They are a great way to generate discussion around new ideas and recruit people to help out. Because we don’t have major organizational decisions, Pull Requests let people see what’s being worked on and they hop in where they think they’ll add the most value. It works a lot like an Open Source project.
Some tricks to make Pull Requests more awesome for your project:
Open a Pull Request as early as possible
Pull Requests are a great way to start a conversation of a feature, so start
one as soon as possible- even before you are finished with the code. Your
team can comment on the feature as it evolves, instead of providing all
their feedback at the very end.
Pull Requests work branch to branch
No one has a fork of
github/github. We make Pull Requests in the same repository by opening Pull Requests for branches.
A Pull Request doesn’t have to be merged
Pull Requests are easy to make and a great way to get feedback and track
progress on a branch. But some ideas don’t make it. It’s okay to close a
Pull Request without merging; we do it all the time.