Go Wiki: コードレビュー
まず、公式の貢献ガイドからコードレビュープロセスに精通していることを確認してください。
レビュー担当者の専門用語
コードレビュー担当者が使用する可能性のあるいくつかの用語に慣れておく必要があります。
LGTM— 私には良さそうに見える (looks good to me)SGTM— 私には良さそうに聞こえる (sounds good to me)PTAL— ご覧ください (please take a look)s/foo/bar/—fooをbarに置き換えてください。これは sed の構文です。s/foo/bar/g— 変更全体でfooをbarに置き換えてください。
CL ディレクティブ
R=foo— Go CL ダッシュボード内でレビュー担当者を割り当てますDO NOT SUBMIT(コミットメッセージ内) — 送信をブロックします。以下の「進行中の作業」セクションを参照してください。Updates #1234またはFixes #1234(コミットメッセージ内) — GitHub イシューから CL をリンクし、オプションで CL がマージされた後にイシューを閉じます。
メール
コードレビューからのメッセージは通常、3 か所に送信されます。
- レビュー担当者 (いる場合)
- golang-codereviews グループ
- オーナー
メッセージはGerrit に中継されないため、メールでのコードレビュー返信は**しないでください**。必ずリンクをクリックし、Gerrit で返信を投稿してください。
進行中の作業
レビューの準備ができていない変更がある場合は、CL の説明の 2 行目に大きな**`DO NOT REVIEW`**と記述することで、それを見た人がそれ以上見ないようにすることができます。これを 1 行目にしないでください。そうしないと、説明を変更した後でも、レビュー全体の件名になってしまいます。
同様に、誤って変更がマージされないようにしたい場合は、CL の説明の 2 行目に**`DO NOT SUBMIT`**と記述できます。
Gerrit の機能が必要ないが、作業をバックアップしたい、複数のクライアント間で作業を共有したい、または変更を検査するためのステージング UI が必要な場合は、通常の Git リモートを使用できます。
GitHub を Git リモートとして使用するには、github.com/golang/go をフォークするか、新しいリポジトリを作成します。それぞれにトレードオフがあります。フォークされたリポジトリは最初のプッシュが速くなります。フォークされていないリポジトリはプライベートにできます。フォークされたリポジトリは GitHub のシステムに関連付けられています。その結果、簡単に発見でき、GitHub UI でクロスリポジトリ比較をサポートします。ただし、これは、フォークされたリポジトリのコミットメッセージ内のイシューへの参照が、イシュー内でフォークへの参照を作成することも意味します。
Git リモートを追加するには、次のように実行します。
$ git remote add fork git@github.com:yourusername/go.git
その後、`git push fork branchname` を使用して「fork」リモートに変更をプッシュできます。
Gerrit のコードレビューモデルは、単一のコミットが正しくなるまで書き換えることです。GitHub は、既存のブランチを誤って上書きするのを防ごうとします。これを回避するには、プッシュを強制します: `git push --force fork branchname`。または、最初にクローンするときに、次のようにしてフォークされたリモートをミラーとして設定することもできます。
$ git remote add --mirror=push fork git@github.com:yourusername/go.git
その後、`git push fork` を実行すると、GitHub は**すべて** (すべてのブランチ、すべてのタグなど) を完全にミラーリングするように更新されます。これは便利ですが、複数のクライアントで使用する場合は注意が必要です。通常の Git の安全策を回避しているため、別のクライアントによってプッシュされた作業を上書き (したがって失う) するのは簡単です。
このコンテンツはGo Wikiの一部です。