Is a pull request equivalent to a (formal Fagan) Code Review?
The Short Story
Well... Maybe yes if you do some additional work over BB/Git.
Out of the box: NO.
First, remember what is a pull request (and what it is good for):
https://help.github.com/articles/about-pull-requests/
https://help.github.com/articles/creating-a-pull-request/
https://help.github.com/articles/requesting-a-pull-request-review/
https://help.github.com/articles/about-pull-requests/
https://help.github.com/articles/creating-a-pull-request/
https://help.github.com/articles/requesting-a-pull-request-review/
Why aren't they equivalent?
Because formal review procedures typically require the creation of review records (CRRs are separate - potentially deliverable - documents that identify the scope of the review, the reviewers, the subject under review and all the issues identified) and the collection of metrics that might be checked against (code review) performance baselines in order to evaluate the quality of the review being performed and feed the continuous improvement process.
Because formal review procedures typically require the creation of review records (CRRs are separate - potentially deliverable - documents that identify the scope of the review, the reviewers, the subject under review and all the issues identified) and the collection of metrics that might be checked against (code review) performance baselines in order to evaluate the quality of the review being performed and feed the continuous improvement process.
The Long Story
If you do not generate CRRs you might get into re-certification issues (difficulties showing compliance, verifiability and making the records auditable) or contractual issues (if the customer needs and/or demands you evidence of code reviews being performed).So it is a good mechanism to improve code quality but they could not replace totally a formal [Fagan] code review unless you generate (manually or automatically with some bespoke scripting) CRRs.
INTERNAL: Projects should use a lot pull requests (since they also contribute to code quality improvements even though efficacy and efficiency are hard to attest and prove), and code reviews at Crucible (the official tool for CR) when compliance is needed internally (with the Verification Process: Large projects, Large Teams, budgets >= 125 KEUR) and/or when review records are needed for the customer or the standards of the target market.
Kudos to D. Almeida for the distinction of the 2 (apparently) similar and redundant mechanisms.