回答:
Facebookがphabricatorと呼ばれる独自のアプリでそれをどのように行うかを見てください：http ://phabricator.org/
基本的には問題ごとにコミットし、問題ごとにコードが表示されます。コードは誰かがレビューする必要があります。レビュアーがそうしてもいいと言うまで、コードはメインのリポジトリには入りません。
それはもっと楽しくなると思います。
また、おそらくコードは2人に割り当てる必要があります。1人はコードを実行し、もう1人はレビューします。
おそらく、あなたのチームメイトは、このレビューを信じられないでしょう。
個人的には、レビュアーがいないため、下位レベルの機能にはユニットテストを使用し、残りのすべてには「管理者テスト」を使用しました。管理者でもコードを理解できるため、管理者テストはそのように呼ばれます。
私は通常、ブロック/関数スコープブラケット、可視性表記、時には型などのいくつかのマイナーパーツを削除し、マネージャー、ドメインエキスパート、仲間にコードを要求した人に見せました。
また、個人的にそこに行き、レビューが完了するまで離れないことが役立ちます。
または、チームに不満がある場合、またはチームに不満がある場合は、「会社を変えることができれば、会社を変えることができます」...
これは、いくつかの前提に基づいて行います。
レビューを完了した人にのみコードのチェックインを許可します。
たぶん、特定の時間のブロックがコードのレビューに専念して、混乱の問題を回避することを期待できます。
目標は、品質コードをチェックインすることです。誰もが「ゴム印」の承認を与えるまで、レビューを罰したり強制したりしたくありません。
異なるレベル（jr。、sr。など）がある場合、昇進とタイトルの維持は、仕事を行うことを条件とする必要があります。
以前のいくつかの雇用主で、私たちは毎日コードレビューに参加していた人を交代させました。通常、3人がCRを共有し、各CRは2人のレビュアーによって承認されなければなりませんでした。これにより、他のプロジェクトに関係なく、その日がCRであることを確実に把握できました。5日ごとに、あなたの番であり、それに応じて開発タスクを調整できます。
現在、チームリーダーがチームのコードに対して大まかなCRを実行しています。アプリケーションのどの領域が更新されたかに応じて、CRが完了した後、グローバルレビューチームにバンプし、アプリケーションにグローバルな影響を与えるものではなく、グローバルな影響を与えるものをチェックします。単一の機能に関連しています。大規模なレビューが行われる場合、通常は数人のユーザーの間でそれを分割するため、1人のユーザーがとんでもない数のファイル全体の変更に対処する必要はありません。
とはいえ、現在のDevブランチ/バリアントにコミットされたコードのみをレビューしています。コードは、コードレビュー、グローバルレビュー、DBレビュー、およびUIレビュー（それぞれ必要に応じて）を通過してからでないと、次の環境（アルファなど）に昇格できません。
最後に、レビューがどれほど迅速に処理されるかに関するSLAに同意します。48時間以上キューに入れられるものはほとんどなく、ほとんどのレビューは24時間以内に行われます。
私が働いている会社では、コミットする前にすべてのコードを他の開発者がレビューする必要があります。私のチームのメンバーはしばしばイライラしています...
ミッションクリティカルなソフトウェアまたは実稼働リリース候補コードへの重要なパッチを作成している場合を除き、特定の種類のコードレビューを厳守する説得力のある理由はありません。
あなたの靴の中を歩いて、私は最初に、コミット後のコードレビューはコミット前のものと同等に尊敬されると管理者に指摘します。これらの用語はWeb 上で検索できます-必要に応じて、バックアップするための参照があります。100％レビューされたコードを取得するために、必ずしも事前にレビューをレビューする必要はありません。
上記に基づいて、次にマイクロ管理の態度をやめ、開発者が自分にとってより便利な方法を試せるようにすることを提案します。コミット前またはコミット後のレビューは、プログラマーが選択するのに最適です。会社がプログラマよりもよく知っているなら、なぜ彼らは自分でコードを書かないのですか？
対処すべき多くの問題があります。心をつかむ必要があり、コードレビューのために時間を確保する必要があります。
2番目の部分はおそらく最も簡単です-開発者が毎朝最初に行うことはコードレビューであることに同意します（まとめて管理を含める必要があります）。従わない場合 より良いのは、何も中断せず、彼らのコードでの作業を停止するように頼まないことです。
最初の部分は本当の問題です-レビュープロセスの参加者は、コードを書いたりバグを修正したりするときに（価値を持たないと見なされる）コードレビューを行わないように、価値があると見なさなければなりません確かにより重要です...？）。
2つを組み合わせることができる場合-最初に誰もがコードレビューに価値があると信じている（または理解している）ことを確認する-最も基本的には、より少ないバグを意味し、通常はより楽しい新しいコードを意味し、次に2番目に配置するコードレビューを行うためのスケジュールに明確なスペースがあるようにすることで、うまくいけば良いことが起こるでしょう...それは文化の一部になります。
文化の一部になったら、「毎日最初のこと」と言う必要はなくなるかもしれませんが、開発者に働きかけたいパターンにぴったりだと思います。
私が働いていたほとんどの企業では、レビューを完了するのに3日かかります。レビューを行わないことは認められません。それはあなたの仕事の一部です。時間内に適切なレビューを行わないと、パフォーマンス評価に影響します。そして、はい、レビューは常に最も不適切な時期に行われるようです。残念ですが、見積もりにレビュー時間を含めることを学んでください。とにかく、管理者がレビューが重要であると本当に信じている（つまり、すべてのコードをレビューすることを義務付けている）場合、同様のポリシーをプッシュします。さらに、割り当てられた時間内に人々がレビューを完了しない場合、それは材料の受け入れになります。
Review Boardのようなツールの使用を検討してください。特に長いレビューには非常に役立ちます。
差分をアップロードして、レビュー担当者がレビューを完了するまで待つことができます。作業の継続を妨げるようなオープンなレビューがある場合は、毎日のミーティング中にこれを報告できます（チームは、できるだけ早くテストできるように、新しい機能をチェックインする必要がありますよね？）。
追加するいくつかのポイントは、他の回答にはありません。
レビューするコードはチェックインする必要があります
ブロッキングタスクが優先されるため、コードレビューは他の作業よりも優先される必要があります（ただし、フローを中断しないようにしてください）。開発者は、コードを改善することを目指しているため、他の人にコードをレビューしてもらう必要があります。その知識では、他の人のレビューを迅速に実行する必要があります。
難しい質問は、いつ、どのようにコードレビューを行うかです。
いつ私たちのために働いたルールは、単一のアプリケーションのコードでは（特にテスト駆動開発を使用している場合）、それほど重要ではないのに対し、共有コードはより大きな影響があるのでレビューする必要があるということです。