トランクにコミットする前にコードを確認する最良の方法は何ですか？ （SVN）
SVNトランクにコミットする前にコードを確認する最良の方法は何ですか？私が考えているアイデアの1つは、開発者にコードをブランチにコミットさせ、ブランチのリビジョンをトランクにマージしながらコードをレビューすることです。これは良い習慣ですか？そうでない場合、コードがトランクにコミットされる前にコードを確認するために他に何ができるでしょうか？
ただし、2つの方法があります-提案または「コミット前にレビュー」します。違いのほとんどは、ネガティブおよび/またはポジティブとして見ることができます。 -たとえば、レビューによって引き起こされた変更の追跡なし-これらを個別のコミットとして確認しますか、それとも最終作業のみに関心がありますか？
コミット前にレビュー-ブランチは必要ありません（必要に応じて行うことができます）。レビュー担当者に作業フォルダへのアクセス権を与える必要があります。追跡なしで、レビュー中およびレビュー後にコードを変更できます。レビューによって発生した修正はリポジトリに表示されません。
コミット後のレビュー（ブランチ上）-レビューごとにブランチをスピンする必要があります（ただし、これはすでにワークフローに含まれている場合があります）。レビューのために送信されたコードは、変更を追跡しないと変更できません。誰かがレビューされたブランチをマージし、レビューされたものとされていないものを追跡しなければなりません。
それは主にチームの文化と経験に依存します。信頼できるモデル、レビューの主な目的は何ですか？私は個人的に、コミット後のレビューを好みます。レビューの結果としての変更を追跡できるからです。 GitとGerritを使用して、2つのオプションのバランスをとっています。
- コミットする前に「svn diff」を実行してパッチファイルを生成してください。
- パッチファイルをトランクのクリーンコピーに適用するレビュー担当者に送信します。
- レビューアは、選択した差分ビューアを使用して変更を検討します。
- レビュー担当者がビルドを実行し、テストを実行します。
- すべてが順調に進んだら、変更を確認できることを開発者に伝えます。もし
開発者がステップ1に戻る問題があります。
理想の世界と現実の世界があります。
idealの世界では、すべてのコードがテストされるため、チェックインされたすべてのものが機能するか、1つ以上のテストに失敗したためにコードが壊れているかを確認できます。さらに、経験の浅い人は経験のある人とペアになるので、コードのレビューはその場で行われます（あなたが行くときにコミットします）。
realの世界では、状況は異なります。ビジネスはそれをライブで変更したいと考えていますnowと完全に真っ直ぐに言うと、そうです、後でコードをクリーンアップしてテストケースを追加する時間があることを伝えます。おそらくすべてをコードレビューする時間がなく、テストでカバーされるコードの割合は継続的に減少します。コードレビューの主な理由は、経験の浅い開発者が変更を検討し、「より良い方法（TM）」を提案することにより、ジュニア開発者が上級開発者から（その時間があるときに）学ぶことです。上級の開発者は、レビューされていないコードをコミットするだけです。コードレビューのためだけに分岐してからマージすることは、時間の浪費です。この問題を克服する1つの方法は、毎週2時間程度の定期的なチームミーティングを宣言し、ユーザーがすぐに取り組んだ最近の変更を1つまたは2つ選択し、コードを見て著者にアプローチを「提示」することです。プロジェクターまたは何かで一緒にこれはいくつかの興味深い議論につながる可能性があります（通常はかなり話題から外れます）が、一般にそれを正しく行う方法についての全員の理解を向上させます。さらに、コードを提示しなければならない可能性があるというプレッシャーにより、一部の人々はそれをよりよくすることができます;-)
または、幸運で、それほど忙しくない現実の環境で作業することができます。実際には、プログラマーは虐待される代わりに何をすべきかを高く評価されており、すべてを正しく行う時間があります。この場合、私の答えは次のとおりです。ここで回答で提案されているさまざまな方法のいくつかを試して、どれがあなたのチームに適しているか、そしてあなたが最もうまく働く方法を見てください。
ブランチは、前のジョブのコミット前のレビューで使用した経験に基づいて、問題なく機能するはずです。
当時は、本番リリース候補コードの重要なパッチにのみコミット前のレビューを使用していたため、ブランチはあまりありませんでした（ルーチンの変更は、コミット後のレビューを通じて渡されました）。
すべての変更に対してコミット前のレビューを使用する予定なので、大量のブランチを管理する必要があるかもしれません。開発者が平均して1週間に1つの「レビュー可能な」変更を行うことを期待する場合、チームのすべての開発者に対して毎年約50のブランチを持つことになります。 1、2、3 ...日かかるような小さな作業量を使用している場合は、それに応じて50を2、3、5 ...で乗算します。
以下に、必要に応じて考慮すべきその他の考慮事項をいくつか示します最善の方法。
1.遅延レビューが他のチームメンバーに必要なコードをブロックする場合のケースの処理
コードレビューの期限に関連する競合を確立、監視、解決します。過去のプロジェクトの1つで扱った日常的な変更に対するコミット前のレビューの思い出によると、妥当な期限は約3日であり、心配して開始するのは提出後1日を超えてレビューが完了しない場合です。
比較のために、コミット後のレビューでは、これらの要件ははるかに緩和されています（私は2週間の期限を使用し、1週間後に心配し始めます）-コミット前のレビューを対象としているため、これはおそらく興味深いものではありません。
2.レビュー済みのコードを送信するときに競合をマージする
コードがレビューを待っている間に、レビューされたコードのコミットが、他のユーザーがコミットした競合する変更によってブロックされた場合はどうしますか？
考慮すべきいくつかのオプションは
- 最初にロールバックし、開発者に変更の再実装と再確認を要求する
その場合、チームの士気へのマイナスの影響に対処する必要があるかもしれません。 - マージの責任を他のチームメンバーに渡す（「マージマスター」）
その場合、マージ自体がコミット前のレビューを受ける必要があるかどうかも決定する必要があります。そうであれば、そのマージが別の競合に遭遇した場合にどうするか。 - マージの段階でレビューされたコードに加えられた変更を無視する
その場合、コミットされたコードがレビューされたコードと異なるという事実に関連するチームの士気への悪影響に対処する必要があるかもしれません。 - 衝突を回避する方法を発明する
直接的なアプローチは、特定の一連のファイルを一度に1人の開発者だけが変更できるようにすることです。ただし、これは、ファイルを直接変更しない種類の変更からユーザーを保護するのではなく、内部APIの変更を通じて影響を与えます。また、この種の「悲観的ロック」は、システム全体の変更と深いリファクタリングを非常に厄介なものにすることもわかるでしょう。
比較のために、コミット後のレビューではこのような問題は発生しません（これらは定義により既にマージされているコードを処理するため）。ただし、コミット前のレビューを対象とするため、これはおそらく興味深いものではありません。
3.レビューを待っている開発者をロードする
レビューを送信した開発者が新しいタスクに切り替えるか、何か他のことを行うべきか（たとえば、レビュー担当者を追跡するなど）の明示的なポリシーを確立します。
比較のために、コミット後のレビューには明示的なポリシーはほとんど必要ありません（コードをコミットし、レビューの期限が1〜2週間であることを考慮に入れて次のタスクに進むのは自然なことです）-しかし、コミット前のレビューを対象とするため、これはおそらく面白くない。
レビューが必要な開発の部分は、別のブランチにある必要があります。そのため、ブランチはレビューの時間になる前にすでに存在している必要があります。次に、ステップは次のようにする必要があります。
- レビュー
- 改訂する（おそらく）
- ループして（おそらく）レビューに戻る
- トランクにマージ
マージは難しい部分です。ブランチが独立している時間が長くなるほど、ブランチをトランクにマージするのが難しくなります。 （テストするのも難しいかもしれません。）
クロスマージは可能な解決策です。トランクにマージする前に（ステップ4またはそれ以前、たとえばステップ3またはステップ1の前など）、トランクをブランチにマージします。開発者はそれを実行してテストできます。次に、ブランチはトランクに追いつき、トランクにマージするのが簡単になります。トランクへのマージは、あなた、またはトランクの担当者が行うのが最善です。
一部の人々はクロスマージの代わりにリベースを試みます。一部の人々は、リベースは悪だと主張しています。それは別の議論です。