0

共通のリモート git リポジトリにプッシュされるすべてのコードに対して、レビューの使用を強制したいと考えています。これを実現するためのツールとしてReviewBoardを選択しましたが、コードの一部をリポジトリにプッシュする前にレビューを必須にすることに苦労しています。

残念ながら、git pre-push フックはオプションではありません。私が見る唯一のオプションは、事前受信フックを使用することですが、これらをレビューと結び付けるのはちょっと難しいです。

これを機能させるには、各開発者は次のようなプロセスに従う必要があります。

  • コード、コミット、コード、コミット...
  • レビュー後 (新しいレビューを生成)
  • 問題の修正、コミット、レビュー後 (新しい差分でレビュー チケットを更新するため)
  • レビューが承認されたら (ステータス: 発送します!)、「#review」などのキーワードを使用して再度コミットします (これはコミットする必要があります --変更が必要ない場合は修正します)。
  • ギットプッシュ

pre-receive フックは、キーワードをチェックし、対応するレビューが実際に受け入れられたかどうかをチェックする必要があります。そうでない場合は、エラーで終了します。

プッシュ アクションのラッパーを作成し、これらすべてを適切に処理するカスタマイズされたスクリプトを用意することで、これをより適切に処理できると思います (プッシュする前にレビュー チケットを自動的に作成し、チケット ID を git config ブランチに保存することができます)。 review_ticket を入力して、すべてが終わったらプッシュします)。これは基本的に上記と同じですが、半自動化されています。これは、開発者がブランチを使用する方法を制限することも意味します (必ずしも問題ではありません)。

最後に、開発者にやりたいことを任せることができますが、リモート リポジトリで cron ジョブを実行し、変更がレビューなしでプッシュされたかどうかを確認し (ややこしいことですが)、警告メールを送信します。

ただし、これらのソリューションはすべて「汚い」ように感じます。誰かがそのような環境をセットアップできましたか、またはここで何かヒントを提供できますか? これはすべて共有ホスティングで機能する必要があることに注意してください。私が持っている現在のソフトウェアセットで機能させたいと本当に思っています.

4

1 に答える 1

0

ReviewBoard インストールを検索して、プッシュされているものの HEAD が完了したレビューに存在することを確認する post-receive フックを作成できます。これにより、ワークフローが次のように変更されます。

  • コード、コミット、コード、コミット、コード、コミット...
  • 事後審査
  • 問題の修正、コミット、修正後のコードによるレビュー後
  • ギットプッシュ

これにより、醜いコミット修正を取り除くことができます。

于 2012-07-03T02:42:05.157 に答える