[IgorPartola]

They are a great tool for when you don't have any other way to communicate with the other developers. Code reviews are a great practice, and we all should do more of them. I do it when I get an email like "hey, could you review my code in feature-branch-xyz before I merge it?" It's less friction than doing GitHub-proprietary pull requests, and involves much less pompousness.

[jaegerpicker]

I guess different environments lead to different flows being better but managing code reviews via email sound really horrible to me. There is no good way to track who has actually reviewed the code, no easy way to annotate the code, and no easy way to give the code a seal of approval. Both Bitbucket and github provide good methods that are easily tracked for this. It' one thing to send an email saying please look at this code but It's much more difficult to track who on that email has done the review and who approves the code.

We use feature branches and issue pull requests/code reviews from those feature branches in BitBucket and it's been a universally well received tool and definitely increased the quality of our code reviews and overall code base.

[IgorPartola]

In my original comment I mentioned a setup with a two person team. You know exactly who is reviewing or not reviewing your code in this setup: the other person. The two of you cannot possibly produce so many feature branches that you don't remember your own code that has not yet been reviewed.

If the PR method works for your team, that's great. In my experience, it leads to more friction and the reasons to implement it are usually "best practices" articles like TFA, not actual needs of the team.

[sanderjd]

I really like having code review persisted right there in the repository. I often go back and look at discussions on old pull requests to figure out why we decided to do something one way or another. It's even "higher resolution" than commit messages (which should also be good).