1. ドキュメント
  2. 貢献ガイド

貢献ガイド

Go プロジェクトはすべての貢献者を歓迎します。

このドキュメントは、Go プロジェクトへの貢献プロセスを説明するためのガイドです。このプロセスは、他のオープンソースプロジェクトで採用されているものとは少し異なります。Git と Go の基本的な理解があることを前提としています。

ここにある情報に加えて、Go コミュニティは CodeReview の wiki ページを管理しています。レビュープロセスを学ぶにつれて、自由に wiki に貢献してください。

gccgo フロントエンドは別の場所にあります。詳細は gccgo への貢献 を参照してください。

貢献者になる

概要

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

必要であれば、これらのステップを自動で実行するツールもあります。実行するだけで良いです。

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

この章の残りの部分では、これらの指示について詳しく説明します。上記のステップを完了した場合は (手動またはツールを使用して)、コードを貢献する前に に進んでください。

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

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

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

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

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

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

$ git config --global user.email name@example.com   # change global config
$ 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 にアクセスし、ページの右上メニューバーにある「Generate Password」をクリックします。accounts.google.com にリダイレクトされ、サインインを求められます。
  2. サインイン後、「Configure Git」という見出しのページに移動します。このページには、パーソナライズされたスクリプトが含まれており、ローカルで実行すると、Git が独自の認証キーを保持するように設定されます。このキーは、SSH キーの動作に似ており、サーバーで生成および保存されるキーとペアになっています。
  3. このスクリプトをコピーしてターミナルでローカルに実行し、秘密の認証トークンを .gitcookies ファイルに保存します。Windows コンピューターを使用して cmd を実行している場合は、代わりに黄色のボックス内の指示に従ってコマンドを実行する必要があります。そうでない場合は、通常のスクリプトを実行してください。

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

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

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

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

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

git-codereview コマンドをインストールするには、以下を実行します。

$ go install golang.org/x/review/git-codereview@latest

git コマンドが git-codereview を見つけられるように、git-codereview がシェルパスにインストールされていることを確認してください。以下のコマンドが

$ git codereview help

エラーではなくヘルプテキストを出力することを確認してください。エラーを出力する場合は、$GOPATH/bin が $PATH に含まれていることを確認してください。

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

コードを貢献する前に

プロジェクトはコードパッチを歓迎しますが、物事がうまく調整されるように、作業を開始する前に重要な変更については議論する必要があります。新しいイシューを立てる か、既存のイシュー を担当するかのいずれかの方法で、イシュー追跡システムに貢献の意思を表明することをお勧めします。

どこに貢献するか

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

イシュートラッカーを確認する

どのような貢献をするかすでにわかっている場合でも、アイデアを探している場合でも、イシュートラッカー は常に最初に行くべき場所です。イシューは分類され、ワークフローを管理するためにトリアージされます。

golang.org/x/... リポジトリの大部分も主要な Go イシュートラッカーを使用しています。ただし、これらのリポジトリの一部はイシューを個別に管理しているため、貢献したいリポジトリの正しいトラッカーを必ず確認してください。

ほとんどのイシューには、以下のワークフローラベルのいずれかが付いています。

GitHub の検索機能を使用して、貢献できるイシューを見つけることができます。例:

新しい問題についてはイシューを開く

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

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

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

機密性の高いセキュリティ関連のイシュー (のみ！) は security@golang.org に報告してください。

GitHub 経由で変更を送信する

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

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

いくつか注意すべき点

Gerrit 経由で変更を送信する

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

以下のセクションでは、Gerrit 経由で変更を送信する簡単な手順を説明します。Gerrit との対話の詳細については、Gerrit のドキュメント を参照してください。特に、レビュー UI の概要 および 基本的な Gerrit のウォークスルー — GitHub ユーザー向け のページを読むことをお勧めします。

概要

これが全体のプロセスの概要です。

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

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

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

メインの Go リポジトリ

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

golang.org/x/... リポジトリ

(この例では golang.org/x/tools)
$ git clone https://go.googlesource.com/tools
$ cd tools

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

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

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

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

$ git codereview change
(open $EDITOR)

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

Change-Id: I2fbdbffb3aab626c4b6f56348861b7909e3e8990

このツールは、ソースコードに対して go fmt を実行したこと、およびコミットメッセージが 提案された形式 に従っていることも確認します。

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

各ブランチには常に単一のコミットを保持するようにしてください。誤って複数のコミットを追加してしまった場合は、git rebase を使用してそれらを 1 つにスカッシュする ことができます。

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

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

メインの Go リポジトリで

標準ライブラリパッケージの場合、パッケージ内のすべてのテストがパスする必要があります。

$ go test

ツリー全体の短いテストスイートは all.bash で実行できます (Windows でビルドするには all.bat を使用します)。

$ cd go/src
$ ./all.bash

しばらく実行して多くのテスト出力を表示した後、コマンドは次のメッセージを出力して終了するはずです。

ALL TESTS PASSED

テストスイートを実行せずにコンパイラと標準ライブラリのみをビルドするには、all.bash の代わりに make.bash を使用できます。go ツールがビルドされると、Go リポジトリをクローンしたディレクトリの bin/go としてインストールされ、そこから直接実行できます。変更を迅速にテストする 方法に関するセクションも参照してください。

golang.org/x/... リポジトリで

リポジトリ全体のテストを実行します (この例では golang.org/x/tools)

$ cd tools
$ go test ./...

ビルドステータスが気になる場合は、ビルドダッシュボード を確認できます。テストの失敗は、コードレビューの TryBots でも捕捉される可能性があります。

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

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

変更が準備され、ツリー全体でテストされたら、レビューのために送信します。これは mail サブコマンドで行われますが、その名前とは異なり、直接メールを送信するわけではありません。単に変更を Gerrit に送信するだけです。

$ git codereview mail

Gerrit は変更に番号と URL を割り当てます。git codereview mail は、次のようなものを表示します。

remote: New Changes:
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 でコミットを修正します。

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

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

繰り返しになりますが、各ブランチには常に単一のコミットを保持するようにしてください。誤って複数のコミットを追加してしまった場合は、git rebase を使用してそれらを 1 つにスカッシュする ことができます。

良いコミットメッセージ

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

良い例を以下に示します。

math: improve Sin, Cos and Tan precision for very large arguments

The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.

The algorithm is described at https://wikipedia.org/wiki/McGillicutty_Algorithm

Fixes #159

1行目

変更説明の最初の行は、慣例として、変更の短い1行の要約であり、主に影響を受けるパッケージが接頭辞として付きます。

経験則として、「この変更は Go を _____ に変更します」という文を完成させるように書くべきです。つまり、大文字で始まらず、完全な文ではなく、変更の結果を実際に要約しています。

最初の行の後に空白行を続けます。

本文

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

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

イシューの参照

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

変更がイシューの解決に向けた部分的なステップである場合は、代わりに「Updates #12345」と記述します。これにより、Gerrit の変更にリンクするコメントがイシューに残されますが、変更が適用されてもイシューはクローズされません。

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

レビュープロセス

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

初心者のよくある間違い

変更が Gerrit に送信されると、通常数日以内にトリアージされます。メンテナーが確認し、最初のレビューを提供しますが、初めての貢献者の場合は通常、基本的な見た目とよくある間違いに焦点を当てます。これらには次のようなものが含まれます。

トライボット

変更の最初の読解後、メンテナーはトライボット (複数の異なるアーキテクチャで完全なテストスイートを実行するサーバー群) をトリガーします。ほとんどのトライボットは数分で完了し、その時点で Gerrit にリンクが投稿され、結果を確認できます。

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

場合によっては、一部のプラットフォームでツリーが数時間壊れていることがあります。トライボットが報告した失敗があなたのパッチとは関係がないように見える場合は、ビルドダッシュボード にアクセスし、同じ失敗が同じプラットフォームの他の最近のコミットにも表示されているかどうかを確認してください。この場合、メンテナーが状況を理解するのに役立つように、失敗があなたの変更とは関係がないことをGerritのコメントに自由に書き込んでください。また、GitHubのイシューで失敗したエラーメッセージを検索したり、最近更新されたwatchflakesイシューを閲覧したりすることもできます。あなたの変更が古いコミットに基づいているか、他の誰かがすでに問題を修正したように見える場合は、git rebaseを介して最新のマスターコミットにリベースしてみてください。

レビュー

Go コミュニティは非常に徹底したレビューを重視しています。各レビューコメントをチケットのように考えてください。提案を実装するか、レビュー担当者を納得させるか、いずれかの方法でそれに対応して「クローズ」することが期待されます。

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

変更が何度もレビューを通過し、1人以上のレビュー担当者が毎回新しいコメントを付け、再度レビューする前に更新された変更を待つのはごく普通のことです。このサイクルは経験豊富な貢献者にとっても起こるため、落胆しないでください。

投票の慣習

決定に近づくと、レビュー担当者はあなたの変更に Code-Review の「投票」を適用します。可能な投票は2つあります。

提出されるには、変更にはメンテナーからの Code-Review +2 が必要です。

メンテナーは、変更に Hold +1 票を適用して、現時点では提出すべきではない変更 (たとえば、変更内の新しい API の 提案レビュー が完了していないためなど) をマークすることもできます。

提出されるには、変更にメンテナーからの Hold +1 票があってはなりません。

最後に、提出されるには、変更のアップローダーまたは少なくとも Code-Review +1 を投票するレビュー担当者のいずれかの立場で、2 人の Google 従業員の関与が必要です。この要件は、コンプライアンスおよびサプライチェーンセキュリティ上の理由によるものです。

承認された変更の提出

変更が準備できると、メンテナーがその変更を提出し、Gerrit リポジトリへのコミットとして追加します。

承認と提出の2つのステップは別々です。これは、場合によってはメンテナーが承認してもすぐに提出したくない場合があるためです (たとえば、ツリーが一時的にフリーズしている場合など)。

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

あなたの変更が数日間承認されているのに提出されていない場合は、Gerrit にコメントを書き込んで提出を要求しても構いません。

さらに詳しい情報

ここにある情報に加えて、Go コミュニティは CodeReview の wiki ページを管理しています。レビュープロセスについてさらに学ぶにつれて、自由にこのページに貢献してください。

その他のトピック

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

Gopls

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

Gopls の完全なドキュメントは https://go.dokyumento.jp/gopls で確認できます。

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

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

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

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

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

git codereview mail コマンドが失敗する最も一般的な理由は、コミット内のメールアドレスが 登録プロセス で使用したアドレスと一致しないためです。
次のようなメッセージが表示された場合...

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

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

$ git config user.email email@address.com

次に、このコマンドでコミットを修正し、この代替メールアドレスを使用するようにします。

$ git commit --amend --author="Author Name <email@address.com>"

そして、以下を実行して再試行します。

$ git codereview mail

変更をすばやくテストする

コードツリーへのすべての変更に対して all.bash を実行するのは負担が大きい作業です。変更を送信する前に実行することを強く推奨しますが、通常の開発サイクル中には、開発中のパッケージのみをコンパイルしてテストしたい場合があります。

レビュー担当者の指定 / その他への CC

変更を送信するに至る議論などで明示的に指示されない限り、レビュー担当者を指定しない方が良いです。すべての変更は自動的に golang-codereviews@googlegroups.com メーリングリストに CC されます。初めての変更の場合、スパムを防ぐためにメーリングリストに表示されるまでにモデレーションの遅延があるかもしれません。

レビュー担当者を指定したり、関係者に CC したりするには、-r または -cc オプションを使用します。どちらもカンマ区切りのメールアドレスリストを受け付けます。

$ git codereview mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com

クライアントの同期

作業中に、他の人がリポジトリに変更を提出している可能性があります。ローカルブランチを更新するには、以下を実行します。

$ git codereview sync

(舞台裏では git pull -r が実行されます。)

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

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

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

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

Git エイリアスの設定

git-codereview コマンドは、例えば次のように入力することでシェルから直接実行できます。

$ git codereview sync

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

$ git sync

git-codereview のサブコマンドは Git 自身のコマンドと区別されるように選ばれているため、これらのエイリアスを定義しても安全です。それらをインストールするには、このテキストを Git 設定ファイル (通常はホームディレクトリの .gitconfig) にコピーしてください。

[alias]
	change = codereview change
	gofmt = codereview gofmt
	mail = codereview mail
	pending = codereview pending
	submit = codereview submit
	sync = codereview sync

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

上級ユーザーは、関連するコミットを単一のブランチにスタックしたい場合があります。Gerrit は、変更が互いに依存し、そのような依存関係チェーンを形成することを可能にします。各変更は個別に承認され、提出される必要がありますが、依存関係はレビュー担当者に見えます。

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

$ git codereview mail HEAD

単一の変更を送信する際には通常必要ありませんが、HEAD を明示的に指定するようにしてください。詳細については、git-codereview ドキュメント を参照してください。

マイナーリリース

バックポートのためにリリースブランチに変更を加える場合は、マイナーリリース を参照してください。

go.dev は、サービスの品質を提供および向上させ、トラフィックを分析するために、Google の Cookie を使用しています。詳細はこちらをご覧ください。