トランクにコミットされる前にコードをレビューする最良の方法は何ですか？（SVN）

SVNトランクにコミットされる前にコードをレビューする最良の方法は何ですか？私が考えているアイデアの1つは、開発者にコードをブランチにコミットさせ、ブランチのリビジョンをトランクにマージしながらコードを確認することです。これは良い習慣ですか？そうでない場合、トランクにコミットされる前にコードをレビューするために他に何ができますか？

ただし、提案するものまたは「コミットする前にレビューする」という2つの学校があります。違いのほとんどは、ネガティブおよび/またはポジティブとして見ることができます。-例：レビューによる変更の追跡なし-これらを個別のコミットとして見たいですか、それとも最終作業のみに関心がありますか？

コミット前にレビュー-ブランチは必要ありません（必要に応じて実行できます）が、レビュー担当者に作業フォルダーへのアクセスを許可する必要があります。コードは、追跡中にレビュー中およびレビュー後に変更できます。レビューによって引き起こされた修正はリポジトリに表示されません。

コミット後のレビュー（ブランチ上）-レビューごとにブランチをスピンする必要があります（ただし、これは既にワークフローに含まれている場合があります）。レビューのために送信されたコードは、変更を追跡せずに変更できません。レビューされたブランチを誰かがマージし、レビューされたものとされていないものを追跡する必要があります。

チームの文化と経験に大きく依存します。モデルを信頼しますか、それがレビューの主な目的ですか？レビューの結果としての変更を追跡できるので、私は個人的にコミット後のレビューを好みます。GitとGerritは、2つのオプションのバランスが取れているため、現在使用しています。

1. コミットする前に、「svn diff」を実行してパッチファイルを生成します。
2. パッチファイルをトランクのクリーンコピーに適用するレビュー担当者に送信します。
3. レビュー担当者は、選択した差分ビューアを使用して変更を検討します。
4. レビュー担当者がビルドを実行し、テストを実行します。
5. すべてうまくいけば、開発者に変更を確認できることを伝えます。
   問題がある場合、開発者はステップ1に戻ります。

理想的な世界があり、現実の世界があります。

では、理想的なのがわから意志のいずれかの作業で確認されますかあなたはそれが1つ以上のテストを失敗したので、それが壊れて知っているよ何でもすることをできるように、世界では、すべてのコードは、テストされています。さらに、それほど経験のない人は経験のある人とペアになります。そのため、コードのレビューはその場で行われます（作業中にコミットします）。

では現実の世界では、物事は異なっています。ビジネスはその変化を今すぐ生かしたいそして、完全にまっすぐな顔で、はい、コードをクリーンアップし、後でテストケースを追加する時間があることを教えてくれます。おそらくすべてをコードでレビューする時間がないため、テストでカバーされるコードの割合は継続的に減少します。コードレビューの主な理由は、経験の浅い人に変更を見てもらい、「より良いやり方（TM）」を提案することにより、ジュニア開発者がシニア開発者から学ぶことです（時間があれば）。上級の開発者は、レビューされていないコードをコミットするだけです。コードレビューのためだけに分岐してからマージするのは、時間の無駄です。この問題を解決する方法の1つは、定期的な週2時間（またはそれ以上）のチームミーティングを宣言することです。プロジェクターまたは何かでコードを一緒に見ることによる彼らのアプローチこれは、いくつかの興味深い議論につながる可能性があります（通常はかなり話題から外れます）加えて、おそらくあなたのコードを提示しなければならないというプレッシャーは、一部の人々がそれをより良くします;-)

または、幸運にも、それほど忙しくない現実の環境で仕事をするようになるかもしれません。プログラマーは虐待される代わりに自分のすることで実際に高く評価されており、すべてを正しく行う時間があります。その場合、私の答えは次のとおりです。ここの回答で提案されているいくつかの異なる方法を試して、どの方法があなたのチームに合っているか、そしてあなたが最もうまくいく方法を確認してください。

ブランチは、以前の仕事でのコミット前のレビューでそれらを使用した私の経験に基づいて、正常に動作するはずです。

_{当時は、本番リリース候補コードの重要なパッチに対してのみコミット前のレビューを使用していたため、ブランチはあまりありませんでした（定期的な変更はコミット後のレビューで渡されました）。}

すべての変更に対してコミット前のレビューを使用するように思われるため、大量のブランチを管理する必要がある場合があります。開発者が平均して1週間に1つの「レビュー可能な」変更を行うことを期待する場合、チーム内のすべての開発者に対して毎年約50のブランチを作成することになります。1、2、3 ...日かかるような小さな作業を使用している場合は、それに応じて50を2、3、5 ...掛けます。

以下は、最良の方法が必要な場合に考慮すべきその他の考慮事項です。

1.遅延レビューが他のチームメンバーに必要なコードをブロックする場合の処理

コードレビューの期限に関連する競合を確立、監視、解決します。過去のプロジェクトの1つで扱った定期的な変更に対するコミット前のレビューを思い出すと、妥当な期限は約3日間であり、心配するのは提出後1日以上でレビューが完了しない場合です。

_{比較のために、コミット後のレビューでは、これらの要件ははるかに緩和されています（2週間の期限を使用しており、1週間後に心配し始めています）-ただし、コミット前のレビューをターゲットにしているため、これはおそらく面白くないでしょう。}

2.レビュー済みコードを送信するときに競合をマージする

コードがレビューを待っている間に他の誰かによってコミットされた変更の競​​合により、レビューされたコードのコミットがブロックされた場合はどうすればよいですか？

考慮すべきいくつかのオプションは

• 最初にロールバックし、開発者に変更の再実装と再レビューを要求する
  その場合、チームの士気へのマイナスの影響に対処する必要があるかもしれません。
• マージの責任を他のチームメンバー（「マージマスター」）に渡し
  ますそのマージは、別の競合につながります。
• マージの段階でレビューされたコードに加えられた変更を無視する
  その場合、コミットされたコードがレビューされたものと異なるという事実に関連するチームの士気への悪影響に対処する必要があるかもしれません。
• 競合を回避する方法を考案する簡単な
  アプローチは、特定のファイルのセットを一度に1人の開発者のみが変更できるようにすることです-ただし、ファイルを直接変更しない種類の変更から保護することはできませんが、内部APIの変更による影響は受けます。また、この種の「悲観的ロック」により、システム全体の変更と深いリファクタリングが非常に面倒になることがわかります。

_{比較のために、コミット後のレビューにはこの種の問題はありません（定義により既にマージされているコードを扱うため）。}

3.レビューを待っている開発者をロードする

レビューを提出した開発者が新しいタスクに切り替えるか、何か他のこと（レビューアを追いかけるなど）を行うかについて、明示的なポリシーを確立します。

_{比較のために、コミット後のレビューには明示的なポリシーはほとんど必要ありません（コードをコミットした後、次のタスクに進むことは当然であり、レビューの締め切りは1週間または2週間であることを考慮しています）面白くない。}

レビューが必要な開発は、別のブランチで行う必要があります。したがって、ブランチはレビューの時が来る前にすでに存在しているはずです。次に、ステップは次のようにする必要があります。

1. レビュー
2. 修正する（おそらく）
3. レビューにループバックする（おそらく）
4. トランクに統合

マージは難しい部分です。ブランチが独立している時間が長いほど、ブランチをブランチにマージするのが難しくなります。（テストするのも難しいかもしれません。）

クロスマージは可能な解決策です。トランクにマージする前に（ステップ4、またはそれ以前、たとえばステップ3またはステップ1の前）、トランクをブランチにマージします。開発者はそれを実行してテストできます。その後、ブランチはトランクに追いつき、トランクにマージしやすくなります。トランクへのマージは、あなた、またはトランクを担当する人が行うのが最適です。

一部の人々は、クロスマージの代わりにリベースを試みます。一部の人々は、リベースは悪だと主張します。それは別の議論です。