Git
英語 ▾ トピック ▾ 最新バージョン ▾ MyFirstContribution 最終更新 2.46.0

概要

これは、Gitツリーに変更を作成し、レビューのために送信し、コメントに基づいて変更を行うという、エンドツーエンドのワークフローを示すチュートリアルです。

前提条件

このチュートリアルでは、ソースコードの管理にGitを使用することに既に精通していることを前提としています。 Gitワークフローの手順については、ほとんど説明しません。

このチュートリアルでは、次のドキュメントを要約することを目的としていますが、読者は役立つ追加のコンテキストを見つけることができます

  • Documentation/SubmittingPatches

  • Documentation/howto/new-command.txt

ヘルプの入手

行き詰まった場合は、次の場所でヘルプを求めることができます。

git@vger.kernel.org

これは、コードレビュー、バージョン発表、設計に関する議論などが行われるメインのGitプロジェクトメーリングリストです。貢献に興味のある方は、ここに質問を投稿してください。 Gitリストでは、プレーンテキストのみのメールが必要であり、メールに返信する際はインライン投稿とボトム投稿が推奨されます。返信はすべてCCされます。必要に応じて、<git+subscribe@vger.kernel.org>にメールを送信することでリストに登録できます（詳細はhttps://subspace.kernel.org/subscribing.htmlを参照）。このメーリングリストのアーカイブは、ブラウザで表示できます。

git-mentoring@googlegroups.com

このメーリングリストは、新しいコントリビューターを対象としており、メインリストの公開の場所以外で質問を投稿し、回答を受け取るための場所として作成されました。新人の指導に特に興味のあるベテランのコントリビューターがリストにいます。検索インデクサーを回避するために、メッセージを表示するにはグループメンバーシップが必要です。誰でも参加でき、承認は必要ありません。

Libera Chatの#git-devel

このIRCチャンネルは、Gitコントリビューター間の会話用です。現在オンラインになっている人がいて、あなたの質問の答えを知っている場合は、リアルタイムでヘルプを受けることができます。それ以外の場合は、スクロールバックを読んで、誰かがあなたに答えたかどうかを確認できます。 IRCではオフラインのプライベートメッセージングが許可されていないため、誰かにプライベートメッセージを送信してからIRCからログアウトすると、相手はあなたに返信できません。切断した場合に回答を得られるように、また他の人が会話から学べるように、チャンネルで質問をすることをお勧めします。

はじめに

Gitリポジトリのクローン作成

Gitは多くの場所にミラーリングされています。それらのいずれかからリポジトリのクローンを作成します。 https://git.dokyumento.jp/downloadsは、クローンに最適な場所の1つとしてGitHubのミラーを提案しています。

$ git clone https://github.com/git/git git
$ cd git

依存関係のインストール

ソースからGitをビルドするには、システムにいくつかの依存関係をインストールする必要があります。必要なもののヒントについては、INSTALLを見て、外部プログラムとライブラリに対するGitの依存関係に関するセクションに特に注意してください。そのドキュメントでは、新しくビルドしたGitをインストールせずに「試運転」する方法について言及しています。このチュートリアルではその方法を使用します。

上記の手順でGitの新しいクローンをビルドすることにより、環境に必要なものがすべて揃っていることを確認してください

$ make
注意
 Gitビルドは並列化可能です。 -j#は上記には含まれていませんが、ここでと他の場所で必要に応じて使用できます。

解決する問題の特定

このチュートリアルでは、新しいコマンドgit psuhを追加します。これは「Pony Saying 'Um、Hello」の略です。これは、ユーザーの典型的な日々のワークフローで頻繁に呼び出されるにもかかわらず、実装されていない機能です。

（slなどの人気のあるコマンドの実装では、この分野で他の取り組みが行われています。）

ワークスペースの設定

まず、変更を処理するための開発ブランチを作成しましょう。 Documentation/SubmittingPatchesによると、真新しいコマンドは新機能であるため、作業のベースをmasterにすることは問題ありません。ただし、将来のバグ修正などについては、そのドキュメントを確認し、適切なブランチに基づいてください。

このドキュメントの目的上、すべての作業のベースをアップストリームプロジェクトのmasterブランチに配置します。開発に使用するpsuhブランチを次のように作成します

$ git checkout -b psuh origin/master

ここでは、複数の変更を含むトピックを同時にレビューに送信する方法を示すために、いくつかのコミットを行います。

コーディング！

注意
 参照実装はhttps://github.com/nasamuffin/git/tree/psuhにあります。

新しいコマンドの追加

多くのサブコマンドはビルトインとして記述されています。つまり、Cで実装され、メインのgit実行可能ファイルにコンパイルされます。非常に単純なpsuhコマンドをビルトインとして実装することで、コードベースの構造、内部API、およびコントリビューターとしてレビュアーおよびメンテナーと協力してこの変更をシステムに統合するプロセスを示します。

ビルトインサブコマンドは通常、「cmd_」の後にサブコマンドの名前が続く関数で実装され、サブコマンドにちなんで名付けられたソースファイルに実装され、builtin/内に含まれます。したがって、コマンドをbuiltin/psuh.cに実装するのが理にかなっています。そのファイルを作成し、その中で、スタイルとシグネチャに一致する関数にコマンドのエントリポイントを記述します

int cmd_psuh(int argc, const char **argv, const char *prefix)

また、psuhの宣言を追加する必要があります。 builtin.hを開き、cmd_pullの宣言を見つけ、宣言をアルファベット順にソートするために、cmd_pullの直前にpsuhの新しい行を追加します

int cmd_psuh(int argc, const char **argv, const char *prefix);

psuh.cに#include "builtin.h"を追加してください。また、出力テキストの印刷に関連する関数を使用するには、#include "gettext.h"する必要があります。

cmd_psuh関数に一時的なprintfを追加します。ビルドルールを追加してコマンドを登録できるようになったため、これは適切な出発点です。

注意
 このチュートリアルの過程で追加するテキストの多くと同様に、一時的なテキストはユーザー向けです。つまり、ローカライズ可能である必要があります。「翻訳のための文字列のマーキング」の下にあるpo/READMEをご覧ください。チュートリアル全体を通して、必要に応じて文字列を翻訳用にマークします。将来、ユーザー向けのコマンドを作成するときにも、そうする必要があります。 
int cmd_psuh(int argc, const char **argv, const char *prefix)
{
	printf(_("Pony saying hello goes here.\n"));
	return 0;
}

ビルドしてみましょう。 Makefileを開き、builtin/pull.oがBUILTIN_OBJSに追加されている場所を見つけ、アルファベット順にbuiltin/psuh.oを同じ方法で追加します。それができたら、トップレベルディレクトリに移動し、単にmakeでビルドします。また、DEVELOPER=1変数を追加して、追加の警告をオンにします

$ echo DEVELOPER=1 >config.mak
$ make
注意
 Gitプロジェクトを開発している場合は、DEVELOPERフラグを使用することをお勧めします。何らかの理由でうまくいかない場合は、オフにすることができますが、問題をメーリングリストに報告することをお勧めします。

これで、新しいコマンドは単独で正常にビルドされます。しかし、誰もそれを呼び出しません。それを変更しましょう。

コマンドのリストは git.c にあります。commands[] 配列に cmd_struct を追加することで、新しいコマンドを登録できます。struct cmd_struct は、コマンド名を表す文字列、コマンド実装への関数ポインタ、およびセットアップオプションフラグを取ります。今のところは、push を模倣し続けましょう。cmd_push が登録されている行を見つけ、それをコピーし、cmd_psuh 用に変更し、新しい行をアルファベット順（cmd_pull の直前）に配置します。

オプションは、builtin.h の「Adding a new built-in」に記載されています。後でユーザーの現在のワークスペースコンテキストに関するデータをいくつか出力したいので、Git ディレクトリが必要なので、唯一のオプションとして RUN_SETUP を選択します。

先に進んで再度ビルドしてください。クリーンビルドが表示されるはずなので、テストを実行して動作するかどうかを確認しましょう。bin-wrappers ディレクトリには、テストに使用できるバイナリがあります。

$ ./bin-wrappers/git psuh

確認してみてください！コマンドができました！よくできました！これをコミットしましょう。

git status は、変更された Makefile、builtin.h、および git.c と、追跡されていない builtin/psuh.c および git-psuh を明らかにします。まず、無視するべきバイナリを処理しましょう。エディタで .gitignore を開き、/git-pull を見つけ、新しいコマンドのエントリをアルファベット順に追加します。

...
/git-prune-packed
/git-psuh
/git-pull
/git-push
/git-quiltimport
/git-range-diff
...

git status をもう一度確認すると、git-psuh が追跡されていないリストから削除され、.gitignore が変更されたリストに追加されているはずです。これでステージングとコミットができます。

$ git add Makefile builtin.h builtin/psuh.c git.c .gitignore
$ git commit -s

コミットメッセージを書くために、エディタが表示されます。コミットは、作業しているコンポーネントの名前を含む50桁以下の件名行で開始し、その後に空行（常に必須）を続け、コミットメッセージの本文を記述します。本文には、変更のコンテキストを詳細に記述する必要があります。特に、差分から簡単に理解できない場合は、変更の「理由」を明示的に記述してください。コミットメッセージを編集する際は、上記の -s によって追加された Signed-off-by トレーラーを削除しないでください。

psuh: add a built-in by popular demand

Internal metrics indicate this is a command many users expect to be
present. So here's an implementation to help drive customer
satisfaction and engagement: a pony which doubtfully greets the user,
or, a Pony Saying "Um, Hello" (PSUH).

This commit message is intentionally formatted to 72 columns per line,
starts with a single line as "commit message subject" that is written as
if to command the codebase to do something (add this, teach a command
that). The body of the message is designed to add information about the
commit that is not readily deduced from reading the associated diff,
such as answering the question "why?".

Signed-off-by: A U Thor <author@example.com>

git show を使用して、新しいコミットを調べてみましょう。"psuh:" は、主に psuh コマンドを変更したことを示しています。件名行は、読者に変更内容の概要を示します。署名行（-s）は、開発者原産地証明書1.1に同意することを示しています（Documentation/SubmittingPatches [[dco]] ヘッダーを参照）。

チュートリアルの残りの部分では、簡潔にするために件名行のみがリストされます。ただし、完全なコミットメッセージの例は、このドキュメントの上部にあるリンク先の参照実装で入手できます。

実装

文字列を出力する以外の何かを行うことは、おそらく役に立つでしょう。まずは、私たちが得るすべてを見てみましょう。

既存の printf() 呼び出しをそのままにして、渡された引数をダンプするように cmd_psuh 実装を変更します。

	int i;

	...

	printf(Q_("Your args (there is %d):\n",
		  "Your args (there are %d):\n",
		  argc),
	       argc);
	for (i = 0; i < argc; i++)
		printf("%d: %s\n", i, argv[i]);

	printf(_("Your current working directory:\n<top-level>%s%s\n"),
	       prefix ? "/" : "", prefix ? prefix : "");

ビルドして試してみてください。予想どおり、コマンドの名前を含め、コマンドラインで指定したものがほとんどそのまま出力されます。（prefix が空の場合は、cd Documentation/ && ../bin-wrappers/git psuh を試してください）。これはあまり役に立ちません。他にどのようなコンテキストを取得できるでしょうか？

#include "config.h" に行を追加します。次に、関数本体に次のビットを追加します。

	const char *cfg_name;

...

	git_config(git_default_config, NULL);
	if (git_config_get_string_tmp("user.name", &cfg_name) > 0)
		printf(_("No name is found in config\n"));
	else
		printf(_("Your name: %s\n"), cfg_name);

git_config() は、Git に既知の設定ファイルから設定を取得し、標準の優先順位ルールを適用します。git_config_get_string_tmp() は、特定のキー（"user.name"）を検索し、その値を提供します。このような単一キー検索関数は多数あります。すべて（および git_config() の使用方法に関する詳細情報）は、Documentation/technical/api-config.txt にあります。

出力された名前が、実行したときに表示される名前と一致することを確認する必要があります。

$ git config --get user.name

素晴らしい！これで、Git 設定で値を確認する方法がわかりました。これもコミットして、進捗を失わないようにしましょう。

$ git add builtin/psuh.c
$ git commit -sm "psuh: show parameters & config opts"
注意
 繰り返しますが、上記は、このチュートリアルで簡潔にするためです。実際の変更では、-m を使用せず、エディターを使用して意味のあるメッセージを作成する必要があります。

それでも、ユーザーの作業コンテキストがどのようなものかを知ることができれば幸いです。ユーザーの現在のブランチの名前を出力できるかどうかを確認してみましょう。git status の実装を模倣できます。プリンターは wt-status.c にあり、ブランチは struct wt_status に保持されていることがわかります。

wt_status_print() は、builtin/commit.c の cmd_status() によって呼び出されます。その実装を見ると、ステータス設定は次のように設定されていることがわかります。

status_init_config(&s, git_status_config);

しかし、詳しく調べていくと、status_init_config() が git_config() の呼び出しをラップしていることがわかります。前のコミットで記述したコードを変更しましょう。

struct wt_status を使用できるように、ヘッダーを含めてください。

#include "wt-status.h"

次に、cmd_psuh 実装を変更して、struct wt_status を宣言し、準備し、その内容を出力します。

	struct wt_status status;

...

	wt_status_prepare(the_repository, &status);
	git_config(git_default_config, &status);

...

	printf(_("Your current branch: %s\n"), status.branch);

もう一度実行してください。確認してみてください - 現在のブランチの（冗長な）名前が表示されます！

これもコミットしましょう。

$ git add builtin/psuh.c
$ git commit -sm "psuh: print the current branch"

それでは、特定のコミットに関する情報を取得できるかどうかを確認してみましょう。

幸いなことに、ここにはいくつかのヘルパーがあります。commit.h には、ハードコードされた文字列を提供できる lookup_commit_reference_by_name という関数があります。pretty.h には、完全なフォーマットオブジェクトを渡す必要のない非常に便利な pp_commit_easy() 呼び出しがあります。

次のインクルードを追加します。

#include "commit.h"
#include "pretty.h"

次に、cmd_psuh() の実装内で、宣言とロジックの近くにそれぞれ次の行を追加します。

	struct commit *c = NULL;
	struct strbuf commitline = STRBUF_INIT;

...

	c = lookup_commit_reference_by_name("origin/master");

	if (c != NULL) {
		pp_commit_easy(CMIT_FMT_ONELINE, c, &commitline);
		printf(_("Current commit: %s\n"), commitline.buf);
	}

struct strbuf は、基本的な char* にいくつかの安全ベルトを提供します。そのうちの1つは、バッファオーバーランを防ぐための長さメンバーです。STRBUF_INIT で適切に初期化する必要があります。char* を渡す必要がある場合は、覚えておいてください。

lookup_commit_reference_by_name は、渡した名前を解決するので、そこで値を操作して、どのようなものが思い浮かぶかを確認できます。

pp_commit_easy は、フォーマット構造体全体ではなく、単一のフォーマット列挙型の省略形を取る pretty.h の便利なラッパーです。その後、その省略形に従ってコミットを pretty-print します。これらは、多くの Git コマンドで --pretty=FOO で使用できるフォーマットに似ています。

ビルドして実行します。例と同じ名前を使用している場合は、あなたが知っている origin/master の最新のコミットの件名行が表示されるはずです。素晴らしい！それもコミットしましょう。

$ git add builtin/psuh.c
$ git commit -sm "psuh: display the top of origin/master"

ドキュメントの追加

素晴らしい！コミュニティと共有する準備ができている素晴らしい新しいコマンドができました。しかし、ちょっと待ってください - これはあまりユーザーフレンドリーではありません。次を実行してください。

$ ./bin-wrappers/git help psuh

新しいコマンドはドキュメント化されていません！それを修正しましょう。

Documentation/git-*.txt を見てください。これらは、Git が知っているサブコマンドのマニュアルページです。これらを開いて、フォーマットに慣れることができますが、その後、新しいファイル `Documentation/git-psuh.txt` を作成してください。Git プロジェクトのほとんどのドキュメントと同様に、ヘルプページは AsciiDoc で記述されています（CodingGuidelines の「Writing Documentation」セクションを参照）。次のテンプレートを使用して、独自のマニュアルページを作成します。

git-psuh(1)
===========

NAME
----
git-psuh - Delight users' typo with a shy horse


SYNOPSIS
--------
[verse]
'git-psuh [<arg>...]'

DESCRIPTION
-----------
...

OPTIONS[[OPTIONS]]
------------------
...

OUTPUT
------
...

GIT
---
Part of the git[1] suite

ここで注意すべき最も重要な部分は、= で下線が引かれたファイルヘッダー、NAME セクション、および通常はコマンドが引数を取る場合に文法を含む SYNOPSIS です。ドキュメントが他の Git および UNIX マニュアルページと一致するように、確立されたマニュアルページヘッダーを使用するようにしてください。これにより、必要な情報が含まれていることがわかっているセクションにスキップできるユーザーの作業が楽になります。

注意
 ドキュメントをビルドする前に、パッケージ `asciidoc` がインストールされていることを確認してください。

マニュアルページを作成したので、明示的にビルドする必要があります。AsciiDoc を、man で読み取り可能な troff に次のように変換します。

$ make all doc
$ man Documentation/git-psuh.1

または

$ make -C Documentation/ git-psuh.1
$ man Documentation/git-psuh.1

これは git help を実行するほど満足のいくものではありませんが、少なくともヘルプページが正しく表示されていることを確認できます。

また、トップレベルから `make check-docs` を実行することで、ドキュメントのカバレッジが良好であること（つまり、プロジェクトがコマンドが実装され、ドキュメント化されていることを認識していること）を確認できます。

新しいドキュメントの変更をコミットしてください。

使用法テキストの追加

./bin-wrappers/git psuh -h を実行してみてください。コマンドは最後にクラッシュするはずです。これは、-h がコマンドが使用法を出力することで処理する必要がある特別なケースであるためです。

Documentation/technical/api-parse-options.txt を見てください。これは、処理できるオプションを取り出すための便利なツールであり、使用法文字列を取ります。

それを使用するには、NULL 終端の usage 文字列の配列と `builtin_psuh_options` 配列を準備する必要があります。

#include "parse-options.h" に行を追加します。

グローバルスコープで、usage 文字列の配列を追加します。

static const char * const psuh_usage[] = {
	N_("git psuh [<arg>...]"),
	NULL,
};

次に、`cmd_psuh()` 実装内で、`option` 構造体を宣言して設定できます。私たちのはかなり退屈ですが、`parse_options()` をさらに詳しく調べたい場合は、さらに追加できます。

	struct option options[] = {
		OPT_END()
	};

最後に、引数とプレフィックスを出力する前に、`parse-options()` への呼び出しを追加します。

	argc = parse_options(argc, argv, prefix, options, psuh_usage, 0);

この呼び出しは、`argv` パラメータを変更します。`options` で指定したオプションを `argv` から削除し、`options` エントリから指し示される場所が更新されます。`argc` を `parse_options()` の結果で置き換えてください。そうでない場合、後で `argv` を解析しようとすると混乱します。

特別な引数 `--` に注意することが重要です。ご存知のとおり、多くの Unix コマンドは `--` を使用して「名前付きパラメータの終わり」を示します - `--` の後のすべてのパラメータは、単なる位置引数として解釈されます。（これは、通常はフラグとして解釈されるものをパラメータとして渡したい場合に便利です。） `parse_options()` は `--` に達すると解析を終了し、残りのオプションをそのまま提供します。

使用ヒントができたので、git help git または git help -a で表示される一般的なコマンドリストにそれを表示する方法を Git に教えることができます。このリストは command-list.txt から生成されます。 _git-pull_ の行を見つけて、アルファベット順に _git-psuh_ の行をその上に追加します。次に、前述のヘルプコマンドでの表示位置に影響を与えるコマンドの属性をいくつか追加します。 command-list.txt の上部には、各属性の意味に関する情報が共有されています。これらのヘルプページでは、コマンドはこれらの属性に従ってソートされます。 git psuh はユーザー向けの、つまり porcelain コマンドなので、「mainporcelain」とマークします。「mainporcelain」コマンドの場合、command-list.txt の上部のコメントには、オプションで別のリストから属性を追加できることが示されています。 git psuh はユーザーのワークスペースに関する情報を表示しますが、何も変更しないため、「info」とマークしましょう。スペースを使用して配置と区切りを行い、属性を command-list.txt の残りの部分と同じスタイルに保ってください。

git-prune-packed                        plumbingmanipulators
git-psuh                                mainporcelain		info
git-pull                                mainporcelain           remote
git-push                                mainporcelain           remote

再度ビルドします。これで、-h を付けて実行すると、使用法が表示され、他の興味深いことが起こる前にコマンドが終了するはずです。素晴らしい！

これもコミットしてください。

テスト

コードをテストすることは重要です。このような小さなトイコマンドであってもです。さらに、テストなしでは、パッチは Git ツリーに受け入れられません。テストでは、以下のことを行う必要があります。

  • 機能の現在の動作を示す

  • 現在の動作が期待される動作と一致することを証明する

  • 外部から見える動作が後の変更で壊れていないことを確認する

それでは、いくつかのテストを書いてみましょう。

関連資料：t/README

テスト構造の概要

Git のテストは t/ にあり、t/README の「Naming Tests」セクションに示されているスキーマを使用して、4 桁の10進数で名前が付けられています。

テストの作成

これはトイコマンドなので、テストの名前を t9999 にしましょう。ただし、family/subcmd の組み合わせの多くは満杯であるため、ベストプラクティスは、追加したものに十分近いコマンドを見つけて、その名前空間を共有することのようです。

新しいファイル t/t9999-psuh-tutorial.sh を作成します。次のようにヘッダーから始めます（t/README の「Writing Tests」と「Source _test-lib.sh_」を参照）

#!/bin/sh

test_description='git-psuh test

This test runs git-psuh and makes sure it does not crash.'

. ./test-lib.sh

TAP 形式の結果を出力するために、テストは test_expect_success の内部に記述されます。 git psuh が正常に終了し、適切な動物について言及していることを確認しましょう。

test_expect_success 'runs correctly with no args and good output' '
	git psuh >actual &&
	grep Pony actual
'

スクリプトの最後に以下を追加して、必要なすべてを実行したことを示します。

test_done

テストスクリプトに実行可能属性を付けてください。

$ chmod +x t/t9999-psuh-tutorial.sh

make -C t test-lint を実行することで、新しいテストスクリプトが正常に作成されたかどうかを確認できます。これは、テスト番号の一意性、実行可能ビットなどをチェックします。

ローカルでの実行

ローカルで実行してみましょう。

$ make
$ cd t/ && prove t9999-psuh-tutorial.sh

完全なテストスイートを実行して、git-psuh が何も壊していないことを確認できます。

$ cd t/
$ prove -j$(nproc) --shuffle t[0-9]*.sh
注意
 make test でこれを行うことも、TAP を理解できるテストハーネスを使用することもできます。 prove は並行して実行できます。 shuffle はテストの実行順序をランダム化するため、テスト間の不要な依存関係に対する耐性が向上します。 prove は出力も見やすくします。

この変更もコミットしてください。

共有の準備：パッチシリーズの構造

Git プロジェクトは、電子メールで送信されたパッチを介してコードレビューを実行し、メンテナーがコミュニティによって承認された準備ができたときに適用することを既に知っているかもしれません。 Git プロジェクトはプルリクエストからのコントリビューションを受け入れておらず、レビューのために電子メールで送信されたパッチは特定の方法でフォーマットする必要があります。

コミットを電子メールで送信されたパッチに変換する方法を見ていく前に、最終結果である「パッチシリーズ」がどのように見えるかを分析してみましょう。 例として、Git メーリングリストアーカイブの Web インターフェース上のパッチシリーズの概要ビューを示します。

2022-02-18 18:40 [PATCH 0/3] libify reflog John Cai via GitGitGadget
2022-02-18 18:40 ` [PATCH 1/3] reflog: libify delete reflog function and helpers John Cai via GitGitGadget
2022-02-18 19:10   ` Ævar Arnfjörð Bjarmason [this message]
2022-02-18 19:39     ` Taylor Blau
2022-02-18 19:48       ` Ævar Arnfjörð Bjarmason
2022-02-18 19:35   ` Taylor Blau
2022-02-21  1:43     ` John Cai
2022-02-21  1:50       ` Taylor Blau
2022-02-23 19:50         ` John Cai
2022-02-18 20:00   ` // other replies elided
2022-02-18 18:40 ` [PATCH 2/3] reflog: call reflog_delete from reflog.c John Cai via GitGitGadget
2022-02-18 19:15   ` Ævar Arnfjörð Bjarmason
2022-02-18 20:26     ` Junio C Hamano
2022-02-18 18:40 ` [PATCH 3/3] stash: call reflog_delete from reflog.c John Cai via GitGitGadget
2022-02-18 19:20   ` Ævar Arnfjörð Bjarmason
2022-02-19  0:21     ` Taylor Blau
2022-02-22  2:36     ` John Cai
2022-02-22 10:51       ` Ævar Arnfjörð Bjarmason
2022-02-18 19:29 ` [PATCH 0/3] libify reflog Ævar Arnfjörð Bjarmason
2022-02-22 18:30 ` [PATCH v2 0/3] libify reflog John Cai via GitGitGadget
2022-02-22 18:30   ` [PATCH v2 1/3] stash: add test to ensure reflog --rewrite --updatref behavior John Cai via GitGitGadget
2022-02-23  8:54     ` Ævar Arnfjörð Bjarmason
2022-02-23 21:27       ` Junio C Hamano
// continued

いくつかの点に注意できます。

  • 各コミットは個別の電子メールとして送信され、コミットメッセージのタイトルが件名として使用され、_n_ コミットシリーズの _i_ 番目のコミットには "[PATCH _i_/_n_]" というプレフィックスが付きます。

  • 各パッチは、シリーズの _カバーレター_ と呼ばれる紹介メールへの返信として送信され、"[PATCH 0/_n_]" というプレフィックスが付きます。

  • パッチシリーズの以降のイテレーションは、「PATCH」の代わりに「PATCH v2」、「PATCH v3」などとラベル付けされます。たとえば、「[PATCH v2 1/3]」は、2 番目のイテレーションの 3 つのパッチのうちの最初のものです。各イテレーションは、新しいカバーレター（上記の "[PATCH v2 0/3]" など）とともに送信され、それ自体は前のイテレーションのカバーレターへの返信です（詳細は以下を参照）。

注意
 単一パッチのトピックは、_i_/_n_ 番号付けなしで "[PATCH]"、"[PATCH v2]" などで送信されます（上記の threads 概要には、単一パッチのトピックは表示されません）。

カバーレター

パッチごとの電子メールに加えて、Git コミュニティはパッチにカバーレターを添付することを期待しています。これは変更の提出において重要な要素であり、パッチを見るだけではわからない、あなたが何をしようとしているのか、そしてなぜそうしようとしているのかをコミュニティに高レベルで説明するものです。

カバーレターのタイトルは、トピックブランチ全体の目的を簡潔に表すものにする必要があります。コミットメッセージのタイトルと同様に、命令形になっていることがよくあります。シリーズのタイトルは次のようになります。

_psuh_ コマンドを追加 ---

カバーレターの本文は、レビュー担当者に追加のコンテキストを提供するために使用されます。パッチだけでは明確にならないことは必ず説明してください。ただし、カバーレターはコミット履歴に記録されないため、リポジトリの履歴の将来の読者にとって役立つ可能性のあるものは、コミットメッセージにも含める必要があることに注意してください。

psuh の本文の例を次に示します。

Our internal metrics indicate widespread interest in the command
git-psuh - that is, many users are trying to use it, but finding it is
unavailable, using some unknown workaround instead.

The following handful of patches add the psuh command and implement some
handy features on top of it.

This patchset is part of the MyFirstContribution tutorial and should not
be merged.

この時点で、チュートリアルは分岐し、パッチセットをフォーマットしてレビューを受けるための 2 つの異なる方法を示します。

最初に説明する方法は GitGitGadget です。これは、GitHub の一般的なプルリクエストワークフローに既に精通しているユーザーに役立ちます。この方法には GitHub アカウントが必要です。

2 番目に説明する方法は git send-email です。これにより、送信される電子メールをよりきめ細かく制御できます。この方法では、システムによって変更される可能性のあるセットアップが必要であり、このチュートリアルでは説明しません。

どちらの方法を選択しても、レビュー担当者とのやり取りは同じです。レビュープロセスは、GitGitGadget と git send-email のセクションの後に説明します。

GitGitGadget を介したパッチの送信

パッチを送信する 1 つのオプションは、典型的なプルリクエストワークフローに従い、GitGitGadget を介してパッチを送信することです。 GitGitGadget は、Johannes Schindelin によって作成されたツールであり、GitHub PR ワークフローに慣れているユーザーにとって、Git コントリビューターとしての生活を楽にするためのものです。コントリビューターは、Git プロジェクトのミラーに対してプルリクエストを開くことができ、PR を一連の電子メールに変換して送信するという魔法のようなことを行います。また、Git の継続的インテグレーションスイートも自動的に実行します。 https://gitgitgadget.github.io/ にドキュメントがあります。

GitHub での git/git のフォーク

GitGitGadget を使用してレビューのためにパッチを送信する前に、Git プロジェクトをフォークして変更をアップロードする必要があります。まず、GitHub アカウントを持っていることを確認してください。

GitHub ミラー にアクセスし、「Fork」ボタンを探します。フォークを適切な場所に配置して作成します。

独自のフォークへのアップロード

ブランチを独自のフォークにアップロードするには、新しいフォークをリモートとして追加する必要があります。 git remote -v を使用して、既に追加したリモートを表示できます。 GitHub の新しいフォークのページで、「Clone or download」を押すと URL を取得できます。次に、以下を実行して追加する必要があります。提供されている例の独自の URL とリモート名を置き換えてください。

$ git remote add remotename git@github.com:remotename/git.git

または、HTTPS URL を使用するには

$ git remote add remotename https://github.com/remotename/git/.git

git remote -v を再度実行すると、新しいリモートが表示されます。プッシュの準備をするために、git fetch remotename（リモートの実際の名前を置き換えます）を実行します。

次に、git branch を実行して、すべての開発を新しいブランチで行っていることを再確認します。そうでない場合は、新しいコミットを独自のブランチに移動することをお勧めします。

このドキュメントの冒頭で簡単に触れたように、作業のベースは master にしているので、以下に示すように、または好みのワークフローを使用して更新してください。

$ git checkout master
$ git pull -r
$ git rebase master psuh

最後に、新しいトピックブランチをプッシュする準備ができました！（ブランチとコマンド名の選択により、以下のコマンドを入力するときは注意してください。）

$ git push remotename psuh

これで、GitHub で新しく作成されたブランチを確認できるはずです。

GitGitGadget への PR の送信

コードをテストしてレビュー用にフォーマットするには、まず gitgitgadget/git に対してプルリクエストを開く必要があります。 https://github.com/gitgitgadget/git にアクセスし、「New pull request」ボタンまたは新しくプッシュされたブランチの名前が表示される場合がある便利な「Compare & pull request」ボタンを使用して PR を開きます。

PR のタイトルと説明は、GitGitGadget によって変更のカバーレターの件名と本文としてそれぞれ使用されるため、レビューしてください。提出のタイトルの付け方と説明に含める内容については、上記の 「カバーレター」 を参照してください。

注意
 単一パッチのコントリビューションの場合、コミットメッセージは既に意味があり、パッチの目的（何が起こっているのか、そしてなぜそうなのか）を高レベルで説明している必要があります。そのため、通常は追加のコンテキストは必要ありません。その場合は、GitHub がコミットメッセージから自動的に生成する PR の説明を削除します（PR の説明は空にする必要があります）。さらにコンテキストを提供する必要がある場合は、そのスペースに提供することができます。これは、GitGitGadget が送信する電子メールの 3 つのダッシュ行と diffstat の間に追加されます（送信後の外観については、ボーナスチャプター：1 パッチの変更 を参照してください）。

問題がなければ、プルリクエストを送信します。

CI の実行と送信の準備

GitGitGadget を初めて使用する（このチュートリアルを使用しているのでそうである可能性が高い）場合は、ツールを使用するための許可を誰かに与えてもらう必要があります。 GitGitGadget のドキュメントで述べられているように、既にそれを使用している誰かに /allow <username> で PR にコメントしてもらう必要があります。 GitGitGadget は、許可がなくても PR を CI で自動的に実行しますが、誰かがツールを使用することを許可するまで、変更を /submit することはできません。

注意
 通常、GitGitGadget で /allow できるユーザーを見つけるには、誰かが /allow を付与された最近のプルリクエストを調べるか（検索：is:pr is:open "/allow"）、作成者と /allow を付与した人の両方が /allow できるようになりました。または、Libera Chat の #git-devel IRC チャネルでプルリクエストにリンクして、誰かに /allow を依頼してください。

CI が失敗した場合は、git rebase -i で変更を更新し、ブランチを再度プッシュできます。

$ git push -f remotename psuh

実際、パッチがnextに受け入れられるまでは、この方法で変更を続けるべきです。

パッチの送信

CIがパスし、誰かが/allowコマンドでGitGitGadgetを使用する許可を与えてくれたので、レビューのために送信するのは、PRに/submitとコメントするだけで完了です。

コメントによる更新

メーリングリストで受け取るレビューコメントへの返信方法については、レビューへの対応を参照してください。

すべてのレビューコメントに従ってブランチを再び希望の形にした後、再度送信できます

$ git push -f remotename psuh

次に、GitGitGadgetに対するプルリクエストを確認してください。CIが再び開始されているはずです。CIが実行されている間は、プルリクエストスレッドの上部にある説明を変更するのに適した時間です。これはカバーレターとして再び使用されます。このスペースを使用して、前回のバージョン以降に変更された内容を説明することで、レビュアーは何を見ているのかを知ることができます。CIの実行が完了したら、/submitともう一度コメントできます。GitGitGadgetは変更に自動的にv2マークを追加します。

git send-emailでパッチを送信する

GitGitGadgetを使用したくない場合は、Git自体を使用してパッチをメールで送信することもできます。この方法でGitを使用する利点には、件名行のよりきめ細かい制御（たとえば、件名にタグ[RFC PATCH]を使用できる）、およびリストに送信する前にすべてが適切に見えることを確認するために自分自身に「ドライラン」メールを送信できることなどがあります。

前提条件：git send-emailの設定

send-emailの設定は、オペレーティングシステムとメールプロバイダーによって異なる場合があるため、このチュートリアルでは、多くのLinuxディストリビューションでは、git-send-emailは通常のgitインストールと一緒にパッケージ化されていないことを述べる以外、説明しません。この追加パッケージをインストールする必要がある場合があります。これを行うのに役立つオンラインリソースが多数あります。また、SMTPサーバーを使用するように設定する適切な方法を決定する必要があります。繰り返しますが、この設定はシステムとメールの設定によって大きく変わる可能性があるため、このチュートリアルの範囲外です。

初期パッチセットの準備

Gitでメールを送信するには、2つの手順があります。メール自体を準備する前に、パッチを準備する必要があります。幸いなことに、これは非常に簡単です

$ git format-patch --cover-letter -o psuh/ --base=auto psuh@{u}..psuh

  1. --cover-letterオプションは、format-patchにカバーレターテンプレートを作成するように指示します。送信する準備ができる前に、テンプレートに入力する必要があります。ただし、今のところ、テンプレートは他のパッチの隣にあります。

  2. -o psuh/オプションは、format-patchにパッチファイルをディレクトリに配置するように指示します。これは、git send-emailがディレクトリを取得してそこからすべてのパッチを送信できるため便利です。

  3. --base=autoオプションは、受信者がパッチシリーズを適用することが想定されている「ベースコミット」を記録するようにコマンドに指示します。auto値により、format-patchはベースコミットを自動的に計算します。これは、リモート追跡ブランチの先端コミットと指定されたリビジョン範囲のマージベースです。

  4. psuh@{u}..psuhオプションは、format-patchに、アップストリーム（「ワークスペースの設定」セクションの例に従った場合はorigin/master）から分岐して以来、psuhブランチで作成したコミットのパッチを生成するように指示します。すでにpsuhブランチにいる場合は、@{u}と言うだけで済みます。これは、「アップストリームから分岐してからの現在のブランチのコミット」と同じです。

コマンドはコミットごとに1つのパッチファイルを作成します。実行後、お気に入りのテキストエディターで各パッチを確認して、すべてが正常に見えることを確認できます。ただし、パッチファイルを介してコードを修正することはお勧めしません。パッチを変更するよりも、git rebase -iを使用するか、新しいコミットを追加して通常の方法で変更を行う方が良いでしょう。

注意
 オプションで、--rfcフラグを使用して、パッチの件名の前に「[PATCH]」ではなく「[RFC PATCH]」を付けることもできます。RFCは「Request for Comments」の略で、コードはまだ送信の準備ができていませんが、コードレビュープロセスを開始したいことを示しています。これは、パッチが提案であるが、コミュニティがそのアプローチで問題を解決したいかどうかがわからない場合にも使用できます。一種の設計レビューを実施するためです。リストに「WIP」とマークされたパッチが表示される場合もあります。これは、パッチが不完全ですが、レビュアーにこれまでの内容を確認してほしいことを意味します。このフラグは、--subject-prefix=WIPで追加できます。

パッチとカバーレターテンプレートが指定したディレクトリに存在することを確認してください。レビューを送信する準備がほぼ整いました。

メールの準備

--cover-letterを指定してformat-patchを呼び出したため、すでにカバーレターテンプレートが用意されています。お気に入りのエディターで開きます。

すでに多くのヘッダーが存在しているはずです。From:ヘッダーが正しいことを確認してください。次に、Subject:を変更します（パッチシリーズの良いタイトルの選び方については、上記を参照してください）

Subject: [PATCH 0/7] Add the 'psuh' command

「[PATCH 0/X]」の部分は必ず残してください。これは、このメールがパッチシリーズの始まりであることをGitコミュニティに示すものであり、多くのレビュアーはこのタイプのフラグでメールをフィルタリングしています。

カバーレターを追加するには、git send-emailを呼び出すときに追加のパラメーターを追加する必要があります。

次に、カバーレターの本文に入力する必要があります。含める内容については、上記を再度参照してください。

git format-patch --cover-letterによって作成されたテンプレートには、diffstatが含まれています。これにより、レビュアーはトピックをレビューする際に何をするのかの概要を知ることができます。サンプル実装のpsuh用に生成されたものは次のようになります

 Documentation/git-psuh.txt | 40 +++++++++++++++++++++
 Makefile                   |  1 +
 builtin.h                  |  1 +
 builtin/psuh.c             | 73 ++++++++++++++++++++++++++++++++++++++
 git.c                      |  1 +
 t/t9999-psuh-tutorial.sh   | 12 +++++++
 6 files changed, 128 insertions(+)
 create mode 100644 Documentation/git-psuh.txt
 create mode 100644 builtin/psuh.c
 create mode 100755 t/t9999-psuh-tutorial.sh

最後に、レターにはパッチの生成に使用されたGitのバージョンが含まれます。その文字列はそのままにしておくことができます。

メールの送信

この時点で、パッチとカバーレターが入ったディレクトリpsuh/があるはずです。メールで送信しましょう！次のように送信できます

$ git send-email --to=target@example.com psuh/*.patch
注意
 返信先アドレスの変更やCCとBCC行の追加など、価値のあるその他のオプションについては、git help send-emailを確認してください。
注意
 CCする相手がわからない場合は、contrib/contacts/git-contactsを実行すると、潜在的なレビュアーを一覧表示できます。さらに、git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch[1]を実行して、このメールのリストを自動的にsend-emailに渡すことができます。
注意
 実際のパッチを送信する場合、git@vger.kernel.orgに送信されますが、チュートリアルからのパッチセットを実際のメーリングリストに送信しないでください！今のところ、どのように見えるかを確認するために、自分自身に送信できます。

上記のコマンドを実行すると、送信される各パッチについてインタラクティブなプロンプトが表示されます。これにより、送信を編集または終了する最後の機会が与えられます（ただし、この方法でコードを編集しないでください）。これらのプロンプトでyまたはaを押すと、メールが送信されます！おめでとうございます！

素晴らしい、これでコミュニティはすべてを中断してあなたの変更をレビューします。（冗談です-我慢してください！）

v2の送信

このセクションでは、パッチセットのv2を送信する方法に焦点を当てます。v2に含める必要がある内容については、レビューへの対応に進んで、レビュアーからのコメントの処理方法を確認してください。

v2には、psuhトピックブランチを再利用します。変更を加える前に、v1ブランチの先端を簡単に参照できるようにマークします

$ git checkout psuh
$ git branch psuh-v1

git rebase -iを使用して、レビュアーのコメントに基づいてコミットを調整することにより、パッチシリーズを調整します。パッチシリーズが送信の準備ができたら、パッチを再度生成しますが、いくつかの新しいフラグを付けて生成します

$ git format-patch -v2 --cover-letter -o psuh/ --range-diff master..psuh-v1 master..

--range-diff master..psuh-v1パラメータは、format-patchに、カバーレターにpsuh-v1とpsuhの範囲差分を含めるように指示します（git-range-diff[1]を参照）。これにより、レビュアーはv1パッチとv2パッチの違いを理解するのに役立ちます。

-v2パラメータは、format-patchにパッチをバージョン「2」として出力するように指示します。たとえば、v2パッチはすべてv2-000n-my-commit-subject.patchのように名前が付けられていることに気付くかもしれません。-v2はまた、パッチの前に「[PATCH]」ではなく「[PATCH v2]」を付けてパッチをフォーマットし、範囲差分の前に「Range-diff against v1」が付きます。

このコマンドを実行すると、format-patchはv1パッチと一緒にpsuh/ディレクトリにパッチを出力します。単一のディレクトリを使用すると、v2パッチの校正中に古いv1パッチを簡単に参照できますが、v2パッチのみを送信するように注意する必要があります。psuh/v2-*.patchのようなパターンを使用します（v1パッチとv2パッチの両方に一致するpsuh/*.patchではありません）。

カバーレターを再度編集します。前回のバージョンと現在のバージョンの違いが重要な場合は、ここで説明することをお勧めします。2番目のカバーレターにまったく同じ本文を含める必要はありません。レビュアーには、目立たない変更点を説明することに焦点を当ててください。

また、前のカバーレターのメッセージIDを見つける必要があります。最初のシリーズを送信するときにgit send-emailの出力からメモするか、メーリングリストで検索できます。アーカイブでカバーレターを見つけ、クリックし、「パーマリンク」または「raw」をクリックしてメッセージIDヘッダーを表示します。以下と一致するはずです

Message-ID: <foo.12345.author@example.com>

メッセージIDは<foo.12345.author@example.com>です。この例は以下でも使用されます。**前のカバーレター**の正しいメッセージIDに置き換えてください。つまり、v2を送信する場合はv1のメッセージIDを使用し、v3を送信する場合はv2のメッセージIDを使用します。

メールを見ている間、CCされている人もメモしておく必要があります。メーリングリストでは、スレッド上のすべてのCCを保持するのが一般的な方法です。これらのCC行は、ヘッダーの（件名行の前に）次のような行でカバーレターに直接追加できます

CC: author@example.com, Othe R <other@example.com>

コマンドに渡すメッセージに注意して、メールを再度送信します

$ git send-email --to=target@example.com
		 --in-reply-to="<foo.12345.author@example.com>"
		 psuh/v2-*.patch

ボーナスチャプター：1パッチの変更

場合によっては、非常に小さな変更が1つのパッチのみで構成される場合があります。その場合、1通のメールを送信するだけで済みます。コミットメッセージはすでに意味があり、パッチの目的（何が起こっているのか、そしてなぜそうなるのか）を高いレベルで説明している必要がありますが、さらにコンテキストを提供する必要がある場合は、パッチの---の下にそうすることができます。単一のコミットでgit format-patchを使用して生成され、---とdiffstatの間にコンテンツを追加するために編集された以下の例を取り上げます。

From 1345bbb3f7ac74abde040c12e737204689a72723 Mon Sep 17 00:00:00 2001
From: A U Thor <author@example.com>
Date: Thu, 18 Apr 2019 15:11:02 -0700
Subject: [PATCH] README: change the grammar

I think it looks better this way. This part of the commit message will
end up in the commit-log.

Signed-off-by: A U Thor <author@example.com>
---
Let's have a wild discussion about grammar on the mailing list. This
part of my email will never end up in the commit log. Here is where I
can add additional context to the mailing list about my intent, outside
of the context of the commit log. This section was added after `git
format-patch` was run, by editing the patch file in a text editor.

 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 88f126184c..38da593a60 100644
--- a/README.md
+++ b/README.md
@@ -3,7 +3,7 @@
 Git - fast, scalable, distributed revision control system
 =========================================================

-Git is a fast, scalable, distributed revision control system with an
+Git is a fast, scalable, and distributed revision control system with an
 unusually rich command set that provides both high-level operations
 and full access to internals.

--
2.21.0.392.gf8f6787159e-goog

パッチがメールで送信されました-次はどうなりますか？

最初のバージョンを送信した後、更新バージョンを送信する前に、レビュー担当者に最初のバッチを処理するのに十分な時間を与えてください。つまり、他の人が最初のバージョンを既にレビューし始めている可能性があるため、すぐに新しいバージョンを送信したいという衝動を抑えてください。

レビューコメントを待っている間に、最初のバッチに間違いが見つかったり、パッチの目標を達成するためのより良い方法が見つかる場合があります。この場合は、次の方法で、調査結果を他のレビュー担当者に伝えることができます。

  • 見つかった間違いが軽微な場合は、レビュー担当者になったかのようにパッチに返信し、更新バージョンで修正することを述べてください。

  • 一方、最初のバッチに対するレビューが（関係者全員にとって）時間の無駄になるほど大幅に方向転換したい場合は、「より良いアプローチに取り組んでいるため、このパッチは無視して、更新バージョンを待ってください」のような返信で、すぐにパッチを撤回してください。

上記は、最初のバッチを十分に洗練せずに送ってしまった場合の良い習慣です。しかし、もちろん、より良いアプローチは、そもそも未熟なパッチを送信しないようにすることです。

レビュー担当者がパッチの各新しいバージョンを調べるのに必要な時間を考慮してください。レビュー担当者は、最初のバージョンをすぐに確認するのではなく（その後、2 日間にわたって「おっと、このバージョンは前のバージョンよりも良い」というパッチがいくつか続きます）、2 日後に洗練された単一のバージョンが提供され、そのバージョンに誤りが少ない方がレビューする必要がある唯一のバージョンであることを強く好みます。

レビューへの対応

数日後、うまくいけば、パッチセットへの返信といくつかのコメントが届きます。やったー！さあ、仕事に戻りましょう。

各コメントに返信し、提案された変更を行ったこと、元のものが優れていると感じていること、またはコメントによって元の変更と提案された変更の両方よりも優れた新しい方法を行うためのアイデアが得られたことをレビュー担当者に通知することをお勧めします。こうすることで、レビュー担当者は、v2 を調べてコメントを実装したかどうかを確認する必要がなくなります。

レビュー担当者は、提案されたコミットログメッセージまたは変更自体の中で、パッチセットに書いた内容について質問することがあります。これらの質問には、返信メッセージで答える必要がありますが、レビュー担当者が書いた内容を理解するためにこれらの質問をした理由は、多くの場合、パッチセットを理解するには明確化が必要だったからです。

返信で質問に答えて、レビュー担当者が言いたいことを理解したと言うだけで満足しないでください。レビュー担当者が問題を抱えていた点を明確にするためにパッチを更新し、v2 を準備します。 v1 を説明するために使用した言葉は、レビュー担当者の質問に答えるために役立つ場合があります。目標は、v2 を十分に明確にして、次に読む人に同じ説明をする必要がなくなるようにすることです。

コメントに反論する場合は、元のものが優れていると感じる理由を丁寧に説明してください。レビュー担当者はまだ同意しない可能性があり、コミュニティの残りのメンバーが一方または他方の側に意見を述べる可能性があることに備えてください。すべてのコードレビューと同様に、最初に計画したものとは異なる方法で行うことに心を開いておくことが重要です。他のレビュー担当者は、あなたとは異なるプロジェクトの視点を持っており、あなたが考えていなかった有効な副作用を考えているかもしれません。変更が提案された理由、またはレビュー担当者があなたに何を求めているのかわからない場合は、いつでも明確にするように依頼してください。

メールクライアントにプレーンテキストメールモードがあり、それがオンになっていることを確認してください。 Git リストは HTML メールを拒否します。また、メンテナーズノートに記載されているメーリングリストのエチケットに従ってください。これは、ほとんどのオープンソースコミュニティにおけるボトム投稿とインライン返信に関するエチケットルールと似ています。

コードを変更する場合、git rebase -i（インタラクティブなリベース）を使用するのが最もきれいです。つまり、結果のコミットが最も見やすくなります。 O'Reilly のこの概要をご覧ください。一般的な考え方は、変更が必要な各コミットを変更することです。こうすることで、間違いのあるパッチ A、v1 でアップストリームレビューを必要としない問題のないパッチ B、および v2 のパッチ A を修正するパッチ C を持つ代わりに、正しいパッチ A と正しいパッチ B を持つ v2 を出荷できます。これは履歴を変更していますが、まだ誰とも共有していないローカル履歴なので、今のところは問題ありません！（後で、これを行うのは理にかなっていない場合があります。このセクションの下のセクションを参照して、コンテキストを確認してください。）

レビュー承認後

Git プロジェクトには、seen、next、master、maint の 4 つの統合ブランチがあります。変更は、レビュープロセス中、まだ初期段階にある間に、メンテナによってかなり早い段階で seen に配置されます。そこから、より広範なテストの準備ができたら、next にマージされます。多くの初期テスターは next を使用し、問題を報告する場合があります。最終的に、next の変更は、通常は安定していると見なされる master に反映されます。最後に、新しいリリースが作成されると、maint がバグ修正の基礎として使用されます。このドキュメントの冒頭で述べたように、さまざまな統合ブランチの使用に関する詳細については、Documents/SubmittingPatches を読むことができます。

現在に戻ります。あなたのコードは、アップストリームのレビュー担当者から賞賛されています。完璧です。受け入れられる準備ができています。他に何もする必要はありません。メンテナはトピックブランチを next にマージし、万事うまくいきます。

ただし、この時点以降にそれほど完璧ではないことがわかった場合は、プロセスのどこにいるかによって、特別な手順を実行する必要がある場合があります。

メンテナが「git.git の料理は何ですか」というメールで、トピックが next にマークされていることを発表した場合、つまり、next にマージする予定はあるが、まだ行っていない場合は、メンテナに少し待つように依頼するメールを送信する必要があります。「シリーズの v4 を送信し、next にマークを付けましたが、これとあれを変更する必要があります。マージする前に v5 をお待ちください。」

トピックが既に next にマージされている場合は、git rebase -i でパッチを変更するのではなく、https://github.com/gitster/git に詳述されているとおり、メンテナのトピックブランチの上に基づいて、別のコミットでさらに変更を加える必要があります。作業はまだ同じトピックにありますが、トピックブランチを全体的に書き直すのではなく、段階的に行われます。

メンテナの GitHub のトピックブランチは GitGitGadget にミラーリングされているため、レビューをその方法で送信する場合は、適切な GitGitGadget/Git ブランチに対して PR を開く必要があります。

git send-email を使用している場合は、以前と同じ方法で使用できますが、差分は <topic>..<mybranch> から生成し、作業の基点は master ではなく <topic> にする必要があります。

1. `contrib/` の下のスクリプトは、コアの `git` バイナリの一部ではなく、直接呼び出す必要があります。 Git コードベースをクローンし、`perl contrib/contacts/git-contacts` を実行します。
scroll-to-top