1. Everything must enter your main branch (master) via Pull Request 2. Everyone can review it. Sometimes more than one person is needed. 3. It's asynchronous - write comments on the code or sit together if you need to see UI / Changes. 4. Code Review should also review unit tests (which pass) 5. Merge PR
This shouldn't block your team and in a week of doing it people will adore this since it will save them at least once.
1) Git log becomes useless.
2) You're merging code via a UI, without ANY granularity whatsoever.
3) Does it not just FEEL dirty doing this in a UI?
4) A little appeal to authority: http://www.wired.com/2012/05/torvalds_github/
5) and a bit more: https://github.com/torvalds/linux/pull/17#issuecomment-56637...
6) Efficiency lost w regards to minor changes. Youd actually write a comment to have someone change something and then RE-issue the pull request? Sure you would, because youre middle management.
Pull requests seem to be a hacky way for management to get involved with something they understand at the loss of control in arguably the most complex phase of coding: INTEGRATION.
FWIW, you're not Linus. You don't get 17 million emails/day (exaggeration, I know). He has a very refined workflow based on many, many years of working with people all over the world on a gigantic project used by hundreds of millions of people.
Re point 6: You don't create another pull request. You just make another commit on that branch.