GITをリポジトリとして使用する場合のコードレビュープロセス？

GITを使用する場合のコードレビューの最適なプロセスは何ですか？外部GITプロバイダー（Unfuddle）があり、リソース使用量に上限があります。そのため、すべての開発者に専用のリモートリポジトリを用意することはできません。

現在のプロセス：

• master誰もがコミットするブランチを持つGITサーバーがあります
• 開発者はローカルmasterミラーまたはローカル機能ブランチから作業します
• 開発者がサーバーのmasterブランチにプッシュ
• 開発者は最後のコミット時にコードレビューをリクエストする

問題：

• コードレビューのすべてのバグは、それがキャッチされるまでにすでにマスターにあります。
• さらに悪いことに、通常、誰かが何が起こったのかを理解しようとして数時間火傷しました...

ですので、

• コードを実行するには、「マスター」に配信する前に確認してください。
• グローバルチームと連携するプロセスを用意する（肩のレビューではありません！）
• 個人の開発者が自分のデスク/マシンに電源を入れて他の誰かがリモートでアクセスできるようにする必要がないもの（人間の依存関係を削除し、開発者が異なるタイムゾーンで家に帰る）

TortoiseGITを使用して、変更されたファイルのリスト、ファイルの差分などを視覚的に表現します。GUIが十分でない場合、GITシェルにドロップする人もいますが、理想的には、ワークフローをシンプルでGUIベースにしたい（私は私のツールではなく、あらゆる負担を取り除くツールを求めています）。

シンプルですが効果的なモデルは、GitHubプルリクエストモデルです。このモデルでは、寄稿者が「コードをマージしてください」リクエストをファイルします。メンテナはチェンジセットをレビューし、さらに作業が必要かどうか、またはマージに適しているかどうかを判断します。その後、彼はmasterブランチにマージできます。通常、コミッターはマスターブランチに直接プッシュすることはできません（これは好みに合わせてカスタマイズできます。「マイナー」コミットを直接実行できます）。

Gitは分散バージョン管理システムです。1つのブランチを持つ1つのリポジトリだけではありません。

複数のリポジトリをセットアップできます（開発者ごとに1つ）。もう1つはマスターリポジトリです。ブランチの1つがマージされる準備ができると、開発者はマージを要求し、それらの変更はブランチ/レポからマスターにプルされます。

そのマージが実際に行われる前に、レビュー担当者は変更を環境にプルし、マスターにプッシュする前にレビューできます。

追加された利点は、このようにして、開発者が互いに干渉したり、お互いの汚れた洗濯物をそれほど見たりすることなく、好きな名前を付けてブランチをいくつでも作成できることです。

また、専門用語を学ぶ：「Devsはサーバーのマスターブランチにコミットする」とは、変更をマスターにプッシュすることを意味しますか？