GITをリポジトリとして使用する場合のコードレビュープロセス？
GITを使用する場合のコードレビューの最適なプロセスは何ですか？外部GITプロバイダー（Unfuddle）があり、リソース使用量に上限があります。そのため、すべての開発者に専用のリモートリポジトリを用意することはできません。
現在のプロセス：
- 誰もがコミットする
masterブランチを持つGITサーバーがあります - 開発者はローカルの
masterミラーまたはローカルの機能ブランチで作業します - 開発者はサーバーの
masterブランチにプッシュします - 開発者は最後のコミット時にコードレビューをリクエストする
問題：
- コードレビューのすべてのバグは、それがキャッチされるまでにすでにマスターにあります。
- さらに悪いことに、通常、誰かが何が起こったのかを理解しようとして数時間火傷しました...
ですので、
- コードを実行するには、「マスター」に配信する前に確認してください。
- グローバルチームと連携するプロセスを用意してください（肩越しにレビューなし！）
- 個人の開発者が自分のデスク/マシンに電源を入れて他の人がリモートでアクセスできるようにする必要がないもの（人間の依存関係を削除し、開発者が異なるタイムゾーンで家に帰る）
TortoiseGITを使用して、変更されたファイルのリスト、ファイルの差分などを視覚的に表現します。GUIが十分でない場合、GITシェルにドロップする人もいますが、理想的には、ワークフローをシンプルでGUIベースにする必要があります（私は私のツールではなく、あらゆる負担を取り除くツールを求めています）。
単純ですが効果的なモデルは GitHubプルリクエスト モデルで、コントリビューターファイルは「コードをマージしてください」というリクエストを送信します。メンテナはチェンジセットをレビューし、さらに作業が必要かどうか、またはマージに適しているかどうかを判断します。その後、彼はmasterブランチにマージできます。通常、コミッターはマスターブランチに直接プッシュすることはできません（これは好みに合わせてカスタマイズできます。「マイナー」コミットを直接実行できます）。
Gitは分散バージョン管理システムです。1つのブランチを持つ1つのリポジトリだけではありません！
複数のリポジトリをセットアップできます-開発者ごとに1つと、マスターリポジトリである別のリポジトリです。ブランチの1つをマージする準備ができると、開発者はマージを要求し、それらの変更はブランチ/レポからマスターにプルされます。
そのマージが実際に行われる前に、レビュー担当者は変更を環境にプルし、マスターにプッシュする前にレビューできます。
追加された利点は、このようにして、開発者が互いに干渉したり、お互いの汚れた洗濯物をそれほど見たりすることなく、好きな名前を付けてブランチをいくつでも作成できることです。
また、専門用語を学びます。「Devs commit to server's master branch」とは、それらがPushマスターへの変更を意味しますか？