貢献者になる

概要

最初のステップは、Goの貢献者として登録し、環境を設定することです。以下の必要な手順のチェックリストがあります:

  • ステップ0:Goに貢献するために使用する単一のGoogleアカウントを決定します。そのアカウントをすべての次のステップに使用し、gitがそのアカウントのメールアドレスでコミットを作成するように設定されていることを確認してください。
  • ステップ1署名して提出 CLA(貢献者ライセンス契約)を行います。
  • ステップ2:Go Gitリポジトリの認証情報を設定します。go.googlesource.comにアクセスし、ページの右上メニューで「パスワードを生成」をクリックし、指示に従います。
  • ステップ3:Goチームが使用するコードレビューツールであるGerritに登録します。このページを訪問してください。CLAと登録は、アカウントに対して一度だけ行う必要があります。
  • ステップ4git-codereviewをインストールします。go install golang.org/x/review/git-codereview@latestを実行してください。

    自動化ツールがあり、これらのステップを案内します。次のコマンドを実行するだけです:

  1. $ go install golang.org/x/tools/cmd/go-contrib-init@latest
  2. $ cd /code/to/edit
  3. $ go-contrib-init

この章の残りの部分では、これらの指示について詳しく説明します。上記の手順を完了した場合(手動またはツールを通じて)、コードの貢献前にジャンプしてください。

ステップ0:Googleアカウントを選択

Goへの貢献は、特定のメールアドレスを持つGoogleアカウントを通じて行われます。プロセス全体を通じて同じアカウントを使用し、すべての後続の貢献に使用することを確認してください。個人のアドレスを使用するか、企業のアドレスを使用するかを決定する必要があるかもしれません。この選択は、あなたが書いて提出するコードの著作権を誰が所有するかによって異なります。このトピックについては、どのアカウントを使用するかを決定する前に雇用主と話し合うことをお勧めします。

Googleアカウントは、Gmailのメールアカウント、G Suiteの組織アカウント、または外部のメールアドレスに関連付けられたアカウントのいずれかです。たとえば、G Suiteを通じて管理されていない既存の企業メールを使用する必要がある場合は、既存のメールアドレスに関連付けられたアカウントを作成することができます。

また、選択したメールアドレスを使用してコミットを作成するようにGitツールが設定されていることを確認する必要があります。Gitをグローバルに設定することも、ローカルに設定することもできます(特定のプロジェクト用)。現在の設定を確認するには、次のコマンドを使用します:

  1. $ git config --global user.email # check current global config
  2. $ git config user.email # check current local config

設定されたアドレスを変更するには:

  1. $ git config --global user.email name@example.com # change global config
  2. $ git config user.email name@example.com # change local config

ステップ1:貢献者ライセンス契約

Goプロジェクトに最初の変更を送信する前に、次の2つのCLAのいずれかを完了している必要があります。どのCLAに署名すべきかは、あなたの作品の著作権を誰が所有しているかによります。

  • あなたが著作権者である場合、個人貢献者ライセンス契約に同意する必要があります。これはオンラインで完了できます。
  • あなたの組織が著作権者である場合、組織は法人貢献者ライセンス契約に同意する必要があります。

    現在署名している契約を確認したり、新しい契約に署名したりするには、Google Developers Contributor License Agreementsのウェブサイトを訪問してください。あなたの貢献の著作権者が他のGoogleオープンソースプロジェクトに関連してすでに契約を完了している場合、再度完了する必要はありません。

    提出するコードの著作権者が変更された場合(たとえば、新しい会社のためにコードに貢献し始めた場合)、golang-devメーリングリストにメールを送信してください。これにより、状況を把握し、適切な契約が完了するようにします。

ステップ2:git認証の設定

主要なGoリポジトリは、GoogleがホストするGitサーバーであるgo.googlesource.comにあります。ウェブサーバーでの認証はGoogleアカウントを通じて行われますが、アクセスするためにgitをコンピュータに設定する必要があります。次の手順に従ってください:

  • 1. go.googlesource.comにアクセスし、ページの右上メニューで「パスワードを生成」をクリックします。アカウントにサインインするためにaccounts.google.comにリダイレクトされます。
  • 2. サインイン後、「Gitを設定する」というタイトルのページに移動します。このページには、ローカルで実行するとGitがあなたのユニークな認証キーを保持するように設定されるパーソナライズされたスクリプトが含まれています。このキーは、サーバー上に生成されて保存されるキーとペアになっており、SSHキーの動作に類似しています。
  • 3. このスクリプトをローカルのターミナルでコピーして実行し、.gitcookiesファイルに秘密の認証トークンを保存します。Windowsコンピュータを使用してcmdを実行している場合は、黄色のボックス内の指示に従ってコマンドを実行してください。そうでない場合は、通常のスクリプトを実行します。

ステップ3:Gerritアカウントを作成

Gerritは、Goのメンテナーがコードの提出を議論し、レビューするために使用するオープンソースツールです。

アカウントを登録するには、go-review.googlesource.com/login/にアクセスし、上記で使用したのと同じGoogleアカウントで一度サインインします。

ステップ4:git-codereviewコマンドをインストール

Goへの変更は、誰が変更を行ったかに関係なく、受け入れられる前にレビューされる必要があります。gitというカスタムコマンドgit-codereviewは、Gerritに変更を送信するのを簡素化します。

  1. ``````bash
  2. $ go install golang.org/x/review/git-codereview@latest
  3. `
  1. ``````bash
  2. $ git codereview help
  3. `

ヘルプテキストが表示され、エラーが表示されないことを確認してください。エラーが表示された場合は、$GOPATH/bin$PATHにあることを確認してください。

Windowsでは、git-bashを使用する場合、git-codereview.exegitの実行パスにあることを確認する必要があります。git --exec-pathを実行して正しい場所を見つけ、シンボリックリンクを作成するか、$GOPATH/binからこのディレクトリに実行可能ファイルをコピーしてください。

コードの貢献前

プロジェクトはコードパッチを歓迎しますが、物事がうまく調整されるように、作業を開始する前に重要な変更について議論する必要があります。問題トラッカーで貢献の意図を示すことをお勧めします。新しい問題を提出するか、既存の問題を主張するかのいずれかです。

どこに貢献するか

Goプロジェクトは、Go言語のソースコードを含む主要なgoリポジトリと、さまざまなgolang.org/x/…リポジトリで構成されています。これらはGoをサポートするさまざまなツールとインフラストラクチャを含んでいます。たとえば、golang.org/x/pkgsitepkg.go.dev用であり、golang.org/x/playgroundはGoプレイグラウンド用であり、golang.org/x/toolsはGoツールのさまざまなツールを含んでいます。Go言語サーバーであるgoplsも含まれています。すべてのgolang.org/x/…リポジトリのリストはgo.googlesource.comで確認できます。

貢献者になる

新しい問題についての問題を開く

非常に些細な変更を除いて、すべての貢献は既存の問題に関連付けられている必要があります。自由に新しい問題を開いて計画を議論してください。このプロセスは、すべての人に設計を検証する機会を提供し、重複作業を防ぎ、アイデアが言語とツールの目標に合致していることを確認します。また、コードが書かれる前に設計が健全であることを確認します。コードレビューのツールは、高レベルの議論の場ではありません。

作業を計画する際、Goプロジェクトは主要なGoリポジトリに対して6か月の開発サイクルに従っていることに注意してください。各サイクルの後半は、バグ修正とドキュメントの更新のみが受け入れられる3か月の機能凍結期間です。機能凍結中に新しい貢献を送信することはできますが、凍結が終了するまでマージされません。凍結は、主要なリポジトリ全体と、リリースに含まれるバイナリをビルドするために必要なgolang.org/x/…リポジトリのコードに適用されます。標準ライブラリにベンダーされているパッケージのリストと、goコマンドを参照してください。

言語、ライブラリ、またはツール(主要なリポジトリおよびすべてのgolang.org/xリポジトリのAPI変更を含む、goコマンドのコマンドライン変更を含む)に対する重要な変更は、受け入れられる前に変更提案プロセスを経る必要があります。

セキュリティ関連の敏感な問題(のみ)は、[email protected]に報告する必要があります。

GitHub経由で変更を送信

すでにGitHubフローに慣れている初めての貢献者は、Goへの貢献に同じプロセスを使用することをお勧めします。GoのメンテナーはコードレビューにGerritを使用していますが、Gopherbotというボットが作成され、GitHubのプルリクエストをGerritに同期します。

通常通りGitHubプルリクエストを開いてください。Gopherbotは対応するGerrit変更リスト(「CL」)を作成し、あなたのGitHubプルリクエストにリンクを投稿します。プルリクエストへの更新もGerrit CLに反映されます。誰かがCLにコメントすると、そのコメントもあなたのプルリクエストに投稿されるため、通知を受け取ります。

注意すべき点:

  • レビューアに応答するには、Gerritアカウントが必要です。提案を実装した場合は、フィードバックを「完了」とマークすることもできます。Gerritに慣れるために、オープンCLをざっと見るか、興味のあるCLの更新を購読する(星アイコンを通じて)か、他の人のCLにレビューまたは+1を付けることをお勧めします。
  • 新しいコードでプルリクエストを更新するには、ブランチにプッシュするだけです。さらにコミットを追加するか、リベースして強制プッシュすることができます(どちらのスタイルも受け入れられます)。
  • リクエストが受け入れられると、すべてのコミットが圧縮され、最終的なコミットの説明はプルリクエストのタイトルと説明を連結して構成されます。個々のコミットの説明は破棄されます。良いコミットメッセージを書くに関する提案を参照してください。
  • 詳細についてはFAQを参照してください。

Gerrit経由で変更を送信

GerritとGitHubを完全に同期させることは現時点では不可能なので、Gerritを学ぶことをお勧めします。異なりますが強力であり、これに慣れることでフローを理解するのに役立ちます。

概要

全体のプロセスの概要は次のとおりです:

  • ステップ1: go.googlesource.comからソースコードをクローンし、1回コンパイルしてテストして安定していることを確認します。
    主要なGoリポジトリに変更を加える場合:
    1. $ git clone https://go.googlesource.com/go
    2. $ cd go/src
    3. $ ./all.bash # compile and test
    golang.org/x/…リポジトリのいずれかに変更を加える場合(この例ではgolang.org/x/tools):
    1. $ git clone https://go.googlesource.com/tools
    2. $ cd tools
    3. $ go test ./... # compile and test
  • ステップ2: マスターブランチから作成された新しいブランチで変更を準備します。変更をコミットするには、git codereview changeを使用します。これにより、ブランチ内に単一のコミットが作成または修正されます。
    1. $ git checkout -b mybranch
    2. $ [edit files...]
    3. $ git add [files...]
    4. $ git codereview change # create commit in the branch
    5. $ [edit again...]
    6. $ git add [files...]
    7. $ git codereview change # amend the existing commit with new changes
    8. $ [etc.]
  • ステップ3: 変更をテストします。編集したパッケージのテストを実行するか、all.bashを再実行します。
    主要なGoリポジトリでは:
    1. $ ./all.bash # recompile and test
    golang.org/x/…リポジトリでは:
    1. $ go test ./... # recompile and test
  • ステップ4: git codereview mailを使用して、Gerritにレビューのために変更を送信します(名前に反して、メールを使用しません)。
    1. $ git codereview mail # send changes to Gerrit
  • ステップ5: レビュー後、同じ単一のコミットに変更を適用し、再度Gerritにメールします:

    1. $ [edit files...]
    2. $ git add [files...]
    3. $ git codereview change # update same commit
    4. $ git codereview mail # send to Gerrit again

    このセクションの残りの部分では、これらのステップについて詳しく説明します。

ステップ1:ソースコードをクローン

最近のGoインストールに加えて、正しいリポジトリからチェックアウトされたソースのローカルコピーが必要です。Goソースリポジトリをローカルファイルシステムの任意の場所にチェックアウトできますが、GOPATHの外にある必要があります(デフォルトでは、ホームディレクトリのgoディレクトリです)。go.googlesource.comからクローンします(GitHubではありません):

主要なGoリポジトリ:

  1. $ git clone https://go.googlesource.com/go
  2. $ cd go

golang.org/x/…リポジトリ
(この例ではgolang.org/x/tools):

  1. $ git clone https://go.googlesource.com/tools
  2. $ cd tools

ステップ2:新しいブランチで変更を準備

各Goの変更は、マスターブランチから作成された別のブランチで行う必要があります。通常のgitコマンドを使用してブランチを作成し、変更をステージングエリアに追加できます:

  1. $ git checkout -b mybranch
  2. $ [edit files...]
  3. $ git add [files...]

変更をコミットするには、git commitの代わりにgit codereview changeを使用します。

  1. $ git codereview change
  2. (open $EDITOR)

お気に入りのエディタでコミットの説明を通常通り編集できます。git codereview changeコマンドは、下部近くにユニークなChange-Id行を自動的に追加します。その行は、Gerritが同じ変更の連続アップロードを一致させるために使用します。編集したり削除したりしないでください。Change-Idは次のようになります:

  1. Change-Id: I2fbdbffb3aab626c4b6f56348861b7909e3e8990

ツールは、go fmtをソースコードに対して実行したことを確認し、コミットメッセージがsuggested formatに従っていることを確認します。

再度ファイルを編集する必要がある場合は、新しい変更をステージングし、git codereview changeを再実行できます。各後続の実行は、Change-Idを保持しながら既存のコミットを修正します。

各ブランチに常に単一のコミットを保持するようにしてください。誤ってさらにコミットを追加した場合は、git rebaseを使用してhttps://stackoverflow.com/questions/31668794/squash-all-your-commits-in-one-before-a-pull-request-in-githubにそれらを1つに圧縮できます。

ステップ3:変更をテスト

あなたはコードを書いてテストしましたが、レビューのためにコードを送信する前に、全体のツリーのすべてのテストを実行して、変更が他のパッケージやプログラムを壊さないことを確認してください。

主要なGoリポジトリで

これはall.bashを実行することで行えます:

  1. $ cd go/src
  2. $ ./all.bash

(Windowsでビルドするにはall.batを使用)

しばらく実行して多くのテスト出力を印刷した後、コマンドは次のように終了します:

  1. ALL TESTS PASSED
  1. <a name="test-xrepo"></a>
  2. #### golang.org/x/...リポジトリで
  3. リポジトリ全体のテストを実行します(この例では[golang.org/x/tools](https://go.googlesource.com/tools)):
  4. ``````bash
  5. $ cd tools
  6. $ go test ./...
  7. `

ビルドステータスが気になる場合は、Build Dashboardを確認できます。テストの失敗は、コードレビューのTryBotsによってもキャッチされる可能性があります。

golang.org/x/vscode-goのような一部のリポジトリは、異なるテストインフラストラクチャを持っているため、作業しているリポジトリのドキュメントを常に確認してください。リポジトリのルートにあるREADMEファイルには通常この情報が含まれています。

ステップ4:レビューのために変更を送信

変更が準備され、ツリー全体でテストされたら、レビューのために送信します。これは、mailサブコマンドを使用して行われますが、その名前にもかかわらず、直接メールを送信するわけではなく、変更をGerritに送信します:

  1. $ git codereview mail

Gerritはあなたの変更に番号とURLを割り当て、git codereview mailが印刷されます。次のようになります:

  1. remote: New Changes:
  2. remote: https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments

エラーが表示された場合は、メールエラーのトラブルシューティングセクションを確認してください。

変更がオープンなGitHubの問題に関連していて、提案されたコミットメッセージ形式に従っている場合、数分以内にボットによって問題が更新され、コメントでGerritの変更にリンクされます。

ステップ5:レビュー後に変更を修正

GoのメンテナーはGerritであなたのコードをレビューし、メールで通知を受け取ります。Gerritでレビューを確認し、そこでコメントできます。好みであれば、メールを使用して返信することもできます。

レビュー後に変更を修正する必要がある場合は、以前に作成したのと同じブランチでファイルを編集し、Gitのステージングエリアに追加し、次にgit codereview changeでコミットを修正します:

  1. $ git codereview change # amend current commit
  2. (open $EDITOR)
  3. $ git codereview mail # send new changes to Gerrit

コミットの説明を変更する必要がない場合は、エディタから保存して終了してください。特別なChange-Id行には触れないでください。

再度、各ブランチに常に単一のコミットを保持するようにしてください。誤ってさらにコミットを追加した場合は、git rebaseを使用してhttps://stackoverflow.com/questions/31668794/squash-all-your-commits-in-one-before-a-pull-request-in-githubにそれらを1つに圧縮できます。

良いコミットメッセージ

Goのコミットメッセージは特定の規則に従います。このセクションではそれについて説明します。

良いコミットメッセージの例は次のとおりです:

  1. math: improve Sin, Cos and Tan precision for very large arguments
  2. The existing implementation has poor numerical properties for
  3. large arguments, so use the McGillicutty algorithm to improve
  4. accuracy above 1e10.
  5. The algorithm is described at https://wikipedia.org/wiki/McGillicutty_Algorithm
  6. Fixes #159

最初の行

変更説明の最初の行は、通常、変更の短い1行の要約であり、主に影響を受けるパッケージによって接頭辞が付けられます。

覚えておくべきルールは、「この変更はGoを_に修正します。」という文を完成させるように書くべきです。つまり、大文字で始まらず、完全な文ではなく、実際に変更の結果を要約します。

最初の行の後に空白行を追加します。

主な内容

説明の残りの部分は詳細を述べ、変更のコンテキストを提供し、何をするのかを説明する必要があります。Goのコメントと同様に、正しい句読点を使用して完全な文で書いてください。HTML、Markdown、または他のマークアップ言語を使用しないでください。

変更がパフォーマンスに影響を与える場合は、ベンチマークデータなどの関連情報を追加してください。変更説明のためにベンチマークデータをフォーマットするために、benchstatツールが通常使用されます。

問題の参照

特別な表記「Fixes #12345」は、変更をGo問題トラッカーの問題12345に関連付けます。この変更が最終的に適用されると、問題トラッカーは自動的にその問題を修正済みとしてマークします。

変更が問題の解決に向けた部分的なステップである場合は、「Updates #12345」と書いてください。これにより、変更にリンクされたコメントが問題に残りますが、変更が適用されても問題は閉じられません。

golang.org/x/…リポジトリに対して変更を送信する場合、変更がメインリポジトリの問題にリンクされることを確認するために、GitHubがサポートする完全修飾構文を使用する必要があります。ほとんどの問題は、メインリポジトリの問題トラッカーで追跡されます。正しい形式は「Fixes golang/go#159」です。

レビューのプロセス

このセクションでは、レビューのプロセスを詳細に説明し、変更が送信された後のレビューへのアプローチ方法を説明します。

一般的な初心者の間違い

変更がGerritに送信されると、通常は数日以内にトリアージされます。メンテナーが確認し、初めての貢献者に対しては通常、基本的な外観や一般的な間違いに焦点を当てた初期レビューが提供されます。これには次のようなことが含まれます:

  • コミットメッセージがsuggested formatに従っていない。
  • リンクされたGitHubの問題がない。ほとんどの変更には、変更が修正または実装するバグや機能を説明するリンクされた問題が必要であり、進行する前にトラッカーで合意が得られている必要があります。Gerritのレビューでは、変更のメリットについて議論することはなく、その実装についてのみ議論します。
  • 開発サイクルの凍結フェーズ中に送信された変更。一般的な変更のためにツリーが閉じられている場合、メンテナーは「R=go1.12」のような行でコードをレビューするかもしれません。これは、ツリーが新しい開発ウィンドウのために開くときにレビューされることを意味します。変更の正しいタイムフレームでないことがわかっている場合は、R=go1.XXをコメントとして追加できます。

Trybots

変更の初期読み込み後、メンテナーはTrybotsをトリガーします。これは、さまざまなアーキテクチャでフルテストスイートを実行するサーバークラスターです。ほとんどのTrybotsは数分で完了し、その時点で結果を確認できるリンクがGerritに投稿されます。

Trybotの実行が失敗した場合は、リンクをたどってテストが失敗したプラットフォームの完全なログを確認してください。何が壊れたのかを理解し、パッチを更新して再度アップロードしてください。メンテナーは、問題が修正されたかどうかを確認するために新しいTrybotの実行をトリガーします。

時には、ツリーが数時間の間にいくつかのプラットフォームで壊れることがあります。Trybotによって報告された失敗がパッチに関連していないように見える場合は、Build Dashboardに移動し、同じプラットフォームの最近のコミットで同じ失敗が表示されるかどうかを確認してください。この場合、Gerritにコメントを書いて、失敗があなたの変更に関連していないことをメンテナーに知らせることができます。

レビュー

Goコミュニティは非常に徹底的なレビューを重視しています。各レビューコメントをチケットのように考えてください。あなたはそれに対処することが期待されており、提案を実装するか、レビューアを納得させる必要があります。

変更を更新した後、レビューコメントを確認し、すべてに返信することを確認してください。「完了」ボタンをクリックして、レビューアの提案を実装したことを示すことができます。そうでない場合は、「返信」をクリックして、なぜそうしなかったのか、または代わりに何をしたのかを説明してください。

変更が数回のレビューを経ることは完全に正常であり、1人または複数のレビューアが毎回新しいコメントを追加し、更新された変更を待って再度レビューします。このサイクルは、経験豊富な貢献者でも発生するため、落胆しないでください。

投票の慣習

決定に近づくにつれて、レビューアはあなたの変更に対してコードレビューの「投票」を適用します。可能な投票は2つあります:

  • +2 変更はマージのために承認されました。+2の投票を行えるのはGoのメンテナー(「承認者」とも呼ばれます)のみです。
  • +1 変更は良さそうですが、レビューアが承認する前に小さな変更を要求しているか、メンテナーではなく承認できないが承認を促したい場合です。

    提出されるには、変更はメンテナーからのコードレビュー+2を持っている必要があります。

    メンテナーはまた、変更が今すぐ提出されるべきではないことを示すために、変更にホールド+1の投票を適用することができます(たとえば、変更に新しいAPIの提案レビューが完了していないため)。

    提出されるには、変更はメンテナーからのホールド+1の投票を持っていない必要があります。

    最後に、提出されるには、変更には2人のGoogle社員の関与が必要です。変更のアップローダーまたは少なくともコードレビュー+1の投票を行うレビューアのいずれかです。この要件は、コンプライアンスとサプライチェーンのセキュリティ上の理由からです。

承認された変更を提出

変更が準備できたら、メンテナーが変更を提出します。これにより、変更がGerritリポジトリにコミットとして追加されます。

承認と提出の2つのステップは別々です。場合によっては、メンテナーが承認したいがすぐに提出したくない場合があります(たとえば、ツリーが一時的に凍結されている可能性があります)。

変更を提出すると、リポジトリにチェックインされます。変更の説明には、コードレビューへのリンクが含まれ、リポジトリ内の変更へのリンクが更新されます。変更を統合するために使用される方法はGitの「チェリーピック」であるため、リポジトリ内のコミットハッシュは提出操作によって変更されます。

変更が数日間承認されたまま提出されていない場合は、Gerritにコメントを書いて提出をリクエストしてください。

詳細情報

ここにある情報に加えて、GoコミュニティはCodeReviewウィキページを維持しています。このページに貢献することを自由に行ってください。

その他のトピック

このセクションでは、問題/編集/コードレビュー/提出プロセス自体の外にあるいくつかの他のコメントを集めています。

Gopls

メインのGoリポジトリで作業し、エディタでgoplsを使用する場合、goコマンドはgoplsによって呼び出され、作業しているソースコードのバージョンに対応している必要があります。goコマンドはmake.bashでビルドでき、binディレクトリはPATHに追加する必要があります。詳細については、Gopls: 高度なトピックを参照してください。

著作権ヘッダー

Goリポジトリ内のファイルには著者名が記載されていません。これは、混乱を避け、リストを最新の状態に保つ必要がないようにするためです。代わりに、あなたの名前は変更ログに表示されます。

あなたが貢献する新しいファイルは、標準の著作権ヘッダーを使用する必要があります:

  1. // Copyright 2024 The Go Authors. All rights reserved.
  2. // Use of this source code is governed by a BSD-style
  3. // license that can be found in the LICENSE file.

リポジトリ内のファイルは追加された年に著作権が付与されます。変更したファイルの著作権年を更新しないでください。

メールエラーのトラブルシューティング

最も一般的なgit codereview mailコマンドの失敗は、コミット内のメールアドレスが登録プロセス中に使用したものと一致しないためです。

もし次のようなものが表示されたら…

  1. remote: Processing changes: refs: 1, done
  2. remote:
  3. remote: ERROR: In commit ab13517fa29487dcf8b0d48916c51639426c5ee9
  4. remote: ERROR: author email address XXXXXXXXXXXXXXXXXXX
  5. remote: ERROR: does not match your user account.

このリポジトリのGitを、登録したメールアドレスを使用するように設定する必要があります。この問題が再発しないようにメールアドレスを変更するには、次のコマンドを実行します:

  1. $ git config user.email email@address.com

次に、このコマンドを使用してコミットをこの代替メールアドレスに変更します:

  1. $ git commit --amend --author="Author Name <[email protected]>"

その後、次のコマンドを実行して再試行します:

  1. $ git codereview mail

変更を迅速にテストする

  1. - 一般的に、`````make.bash``````````all.bash`````の代わりに実行して、全体のテストスイートを実行せずにGoツールチェーンのみを再ビルドできます。または、`````run.bash`````を実行して、ツールチェーンを再ビルドせずに全体のテストスイートを実行できます。`````all.bash``````````make.bash`````の後に`````run.bash`````として考えることができます。
  2. - このセクションでは、Goリポジトリをクローンしたディレクトリを`````$GOROOT`````と呼びます。`````go`````ツールは`````$GOROOT/src/make.bash`````によってビルドされ、`````$GOROOT/bin/go`````にインストールされ、コードをテストするために呼び出すことができます。たとえば、コンパイラを変更し、その変更が自分のプロジェクトのテストスイートにどのように影響するかをテストしたい場合は、次のように`````go````` `````test`````を実行します:
  3. ``````bash
  4. $ cd <MYPROJECTDIR>
  5. $ $GOROOT/bin/go test
  6. `
  • 標準ライブラリを変更している場合、コンパイラを再ビルドする必要はないでしょう: 変更したパッケージのテストを実行するだけで済みます。通常使用しているGoバージョンまたはクローンからビルドしたGoコンパイラのいずれかで実行できます(変更している標準ライブラリのコードが、インストールされている安定版よりも新しいバージョンを必要とする場合があるため、時にはこれが必要です)。
    1. $ cd $GOROOT/src/crypto/sha1
    2. $ [make changes...]
    3. $ $GOROOT/bin/go test .
  • コンパイラ自体を変更している場合、compileツール(これはgo buildによって各パッケージをコンパイルするために呼び出される内部バイナリ)を再コンパイルするだけで済みます。その後、何かをコンパイルまたは実行してテストしたいと思うでしょう。
    1. $ cd $GOROOT/src
    2. $ [make changes...]
    3. $ $GOROOT/bin/go install cmd/compile
    4. $ $GOROOT/bin/go build [something...] # test the new compiler
    5. $ $GOROOT/bin/go run [something...] # test the new compiler
    6. $ $GOROOT/bin/go test [something...] # test the new compiler
    他のGoツールチェーンの内部ツール(asmcoverlinkなど)にも同様のことが当てはまります。go install cmd/<TOOL>を使用してツールを再コンパイルしてインストールし、その後ビルドされたGoバイナリを使用してテストします。
  • 各パッケージの標準テストに加えて、$GOROOT/testにはいくつかのブラックボックスおよび回帰テストを含むトップレベルのテストスイートがあります。テストスイートはall.bashによって実行されますが、手動で実行することもできます:

    1. $ $GOROOT/bin/go test cmd/internal/testdir

レビュアーを指定する / 他の人をCCする

明示的に指示されない限り、変更を送信する前の議論などでは、レビュアーを指定しない方が良いです。すべての変更は自動的に[email protected]メーリングリストにCCされます。これが初めての変更である場合、スパムを防ぐためにメーリングリストに表示されるまでにモデレーションの遅延があるかもしれません。

  1. ``````bash
  2. $ git codereview mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
  3. `

クライアントを同期する

作業中に、他の人がリポジトリに変更を提出しているかもしれません。ローカルブランチを更新するには、次のコマンドを実行します:

  1. $ git codereview sync

(内部では、git pull -rが実行されます。)

他の人のコードをレビューする

レビュー過程の一環として、レビュアーは直接変更を提案できます(GitHubのワークフローでは、これは他の誰かがプルリクエストにコミットを添付することになります)。Gerritは、他の開発者が提案した変更をインポートするのに役立つコマンドへのアクセスを提供しますので、ローカルでレビュー/テストできます。インポートしたいCLのGerritページから、「⋮」メニューを開き、「パッチをダウンロード」リンクをクリックします。好みのgitワークフローに応じて、適切なコマンドを選択します。オプションは次のようになります:

  1. $ git fetch https://go.googlesource.com/review refs/changes/21/13245/1 && git checkout FETCH_HEAD

元に戻すには、作業していたブランチに戻ります。

gitエイリアスを設定する

  1. ``````bash
  2. $ git codereview sync
  3. `

しかし、git-codereviewのサブコマンドのエイリアスを設定する方が便利ですので、上記は次のようになります:

  1. $ git sync
  1. ``````bash
  2. [alias]
  3. change = codereview change
  4. gofmt = codereview gofmt
  5. mail = codereview mail
  6. pending = codereview pending
  7. submit = codereview submit
  8. sync = codereview sync
  9. `

複数の依存変更を送信する

上級ユーザーは、関連するコミットを単一のブランチにスタックすることを望むかもしれません。Gerritは、変更が互いに依存することを許可し、そのような依存関係チェーンを形成します。各変更は別々に承認され、提出される必要がありますが、依存関係はレビュアーに見えるようになります。

依存する変更のグループを送信するには、各変更を同じブランチの異なるコミットとして保持し、次のコマンドを実行します:

  1. $ git codereview mail HEAD

通常、単一の変更を送信する際には必要ないHEADを明示的に指定することを確認してください。詳細については、git-codereviewのドキュメントを参照してください。