My team uses pull requests extensively. The master branch is considered good, clean, production-ready code. Anything you want to get into production gets there by way of a pull request. Want to add a feature? Fix a bug? Make a branch, do your thing, and create a pull request against master. The rest of the team reviews your code in the pull request; the comments in a pull request are an excellent feature. My job would be ridiculously harder without pull requests.
I find pull requests handy for working with semi-technical people, for repos only worked on by programmers we just use the format-patch/email workflow, and we have access to each others public repos (would be called "forks" in github parlance I guess).
It's a much better system, faster, more powerful and more flexible but not centralized and you have to understand what you are doing.
It's not like this is a feature github discovered and added. They made an easier, prettier and less powerful version of an existing feature. Certainly not a bad idea, git's command line UI is ridiculously bad UI so a super simple point and click interface was a fantastic way to grab market share and get non-command line people involved.
> the comments in a pull request are an excellent feature
Really? I mean, compared to nothing I guess it would seem great. But since I'm used to an email thread serving the same purpose those comments on github pull requests seem awful to me.
Exactly, the benefit of Github is exactly what it says on the tin:
"Build software better, together."
Or, like it says on my Github mug:
"Github: social coding."
Seriously, if it's just you the self hosting your git repos is much easier, cheaper, and you'll have a better handle on how git actually works. However, if you're on a team or dealing with other people, the collaborative features of Github are awesome.
Once again, the correct answer is "use the right tool for the job."
Right, I thought one of the big benefits about pull requests was that it let other devs easily view the diffs before merging a change in, not to mention making it easier for people to discuss the changes. I guess if you don't want to do that then it's easier to just pass around patches and merge.
Viewing changes in a pull request is no easier than viewing the changes in a patchset (or rather, if it is you're using the wrong tools). For an established team, a PR-based workflow and a mailing list based workflow (where you mail patchsets to the mailing list and discuss them there) are not very different, but PRs are a lot friendlier to outside contributors.
