Pull Request をマージするのは誰だ - Qiita

チーム開発の現場に git を導入し、git-flow, github-flow などの開発フローに則って、 pull-request とコードレビューを実施している現場も多くあるだろう。 私達のチームもその例に漏れていない。git-flow, github-flow こそ採用はしていないものの、それらをより簡略化、シンプルにしたフローで開発を行ってる。 さて、あなたのチームではコードレビューの後にPull Requestをmergeするのは誰の作業だろうか？レビューをした人？それともレビューを依頼した人？あるいは、ソースコード統括管理担当者？ 私達のチームでは、Pull Requestを作った人(つまり、コードレビューを依頼した人)がソースコードのマージを行うようにルールを作成した。今回は、そのようなルールを導入している理由とメリットや効果について纏る。 レビューに通過！さあ、マージしよ

[moegg]

“私達は Pull Request を作った本人がマージを行うようにルールを作って運用している。この方法にはメリットがある。”

[rytich]

"この方法は「Pull Request に対して自動でテストを行っていること」や「Pull Request と Issue が紐付いていること」が前提条件"