以下是如何通过电子邮件进行几轮审查的步骤：
git format-patch --cover-letter --output-directory patches --thread=shallow
patches/0000-cover-letter*）：添加正文（参见星号）并修复主题（参见星号）Message-ID，它将是电子邮件线程中的第一封电子邮件。每个补丁都会回复封面信（“shallow”样式）。Message-ID；它是文本/补丁文件中的一个电子邮件头git send-email patches发送出去第二轮：
git format-patch，但加入一些额外的选项：
--in-reply-to=<Message-ID>：使用您记录的第一轮中的Message-ID-v 2表示“第二轮”--range-diff <base> <previous tag> <current>以生成封面信的“范围差异”（两个系列/分支之间的差异）
部分内容基于提交补丁。
现在您提出了一些具体的问题：
虽然我能够为每个子任务创建必要的补丁，但我无法在我的讲师邮箱中"某种方式"将这三封电子邮件链接起来。
这更多是一个邮件问题，而不是一个 git 问题。通常情况下，电子邮件通过回复以前的消息进行“连接”；在大多数客户端中，这样的回复链将显示为一条对话“线程”。
因此，在发送第一封电子邮件后，您将会回复它，可能会修改主题，并包括第一个补丁的内容（使用git format-patch生成），并按照同样的方式处理第二个补丁。
您实际上可以使用 git format-patch 和 git send-email 从命令行完成这些操作。首先生成您的补丁：
$ mkdir patches
$ git format-patch -o patches master
然后使用git send-email发送这些补丁，利用--in-reply-to命令行选项将您的消息链接到先前的消息。这需要将先前消息的message-id作为参数传递，因此您需要查看原始消息以获取message-id头的值。然后您可以运行：
git send-email \
--in-reply-to ...message-id-here... \
--from you@your.address \
--to teacher@school.address \
patches
这将发送两封电子邮件，主题看起来像：
[PATCH 1/2] first line of commit message here
并且：
[PATCH 2/2] first line of next commit message here
git会提示您是否要发送它：From: lars@example.com
To: lars@example.com
Subject: [PATCH 1/2] made a patch
Date: Thu, 3 Sep 2015 11:42:23 -0400
Message-Id: <1441294944-28084-1-git-send-email-lars@example.com>
X-Mailer: git-send-email 2.4.0
In-Reply-To: <20150903153652.GE4975@example.com>
References: <20150903153652.GE4975@example.com>
The Cc list above has been expanded by additional
addresses found in the patch commit message. By default
send-email prompts before sending whenever this occurs.
This behavior is controlled by the sendemail.confirm
configuration setting.
For additional information, run 'git send-email --help'.
To retain the current behavior, but squelch this message,
run 'git config --global sendemail.confirm auto'.
Send this email? ([y]es|[n]o|[q]uit|[a]ll):
1 4 sF 03-09-2015 To lars@exampl Test message for git (➥)
2 4 N F 03-09-2015 To lars@exampl └─>[PATCH 1/2] made a patch (✉ me)
3 4 N F 03-09-2015 To lars@exampl └─>[PATCH 2/2] hey look no hands (✉ me)
git help send-email是开始的地方。）--validate option来调用钩子sendemail-validate（即钩子路径中名为'sendemail-validate'的可执行文件（默认情况下为.git/hooks）。git send-email"(man) 学会了尊重core.hooksPath配置，这是一个Git 2.9设置，我之前在这里提到过。
请查看提交 c824393（2021年3月23日），作者为Robert Foss（robertfoss）。
（由Junio C Hamano -- gitster --于2021年3月30日合并至提交 1ba947c）
git-send-email：尊重core.hooksPath设置署名：Robert Foss
署名：Ævar Arnfjörð Bjarmason
get-send-email目前假设存储库中存在 'sendemail-validate' 钩子。自从 867ad08（"
hooks: allow customizing where the hook directory is"，2016-05-04，Git v2.9.0-rc0 -- merge listed in batch #13）引入 'core.hooksPath' 配置选项以来，这不再是真实情况。不要再假定一个
hardcoded存储库相对路径，而是查询 git 获取钩子目录的实际路径。
git send-email --validate"(man) 选项的消息将发生变化。avar) 提交。gitster -- 合并于 commit 2279289, 2021年4月13日)
git-send-email：改进--validate错误输出署名：Ævar Arnfjörð Bjarmason
改善我们在--validate错误时发出的输出，以：system_or_msg()的输出结合起来，说明挂钩死亡时使用了什么退出代码。我曾尝试让行长度检查器注明所有超过限制的行。
我认为这样做不值得，但我已经保留了测试变更，以检查我们是否在发现第一行过长时立即停止。
patch contains a line longer than 998 characters
您有:
is longer than 998 characters\n" .
在 Git 2.35（2022年第一季度）中，命令行完整性对于 "git send-email"(man)选项进行了微调，并提到了 format-patch。
thiagowfx）提交）。gitster --在commit 7c2abf1中合并）
send-email文档：添加format-patch选项签名：Thiago Perrotta
git-send-email(1)没有提到可以接受 "git format-patch"(man) 选项。
增加概要和描述以提及它。
git send-email现在在其手册页中包括：
'git send-email' [<options>] <file|directory>...'git send-email' [<options>] <format-patch options>
[...] 可以传递给
git send-email，也可以理解为git format-patch的选项。
“git send-email -v 3”(man)曾被扩展为git send-email --validate 3，当用户希望将其传递给format-patch时：这已在Git 2.40（2023年第一季度）中进行了更正。
请查看8774aa5提交（2022年11月26日），作者为Kyle Meyer (kyleam)。
（由Junio C Hamano -- gitster --在531d13d提交中合并，日期为2023年1月27日）
send-email中继承了其format-patch调用的无法识别的参数。
send-email：将'-v N'转发到format-patch签署者：Kyle Meyer
-v N'会导致错误，因为-v被视为send-email的--validate。git send-email -v 3 @{u}
fatal: ambiguous argument '3': unknown revision or path not in the
working tree. [...]
--reroll-count添加到send-email的主选项列表中，并在format-patch调用中显式提供它。-n、-N和diff选项-D。GetOptions调用消耗的-v不同，-n、-N和-D选项被较早的调用作为缩写消耗。在 Git 2.41 (2023 年第二季度) 中，sendemail-validate 验证钩子学会通过环境变量传递输入文件的总数以及每个调用在序列中的位置。
请参见 提交 3c8d3ad (2023 年 4 月 14 日)，作者为 Robin Jarry (rjarry)。
(由 Junio C Hamano -- gitster -- 在 提交 c4c9d55 中合并，2023 年 4 月 25 日)
send-email：在验证环境中导出补丁计数器建议者：Phillip Wood
签署者：Robin Jarry
GIT_SENDEMAIL_PATCH_COUNTER和GIT_SENDEMAIL_PATCH_TOTAL环境变量向挂钩公开当前和总补丁数，以便实现增量和全局验证。git config(man) sendemail.validateWorktree条目中。
githooks现在在其手册页面中包含：
GIT_SENDEMAIL_FILE_COUNTER一个基于1的计数器，每个包含要发送的电子邮件的文件都会增加1（不包括任何FIFO）。该计数器不遵循补丁系列计数器方案。它将始终从1开始，并在GIT_SENDEMAIL_FILE_TOTAL结束。
GIT_SENDEMAIL_FILE_TOTAL将被发送的文件总数（不包括任何FIFO）。
该计数器不遵循补丁系列计数器方案。它将始终等于正在发送的文件数量，无论是否有封面信。
例如，这些变量可用于验证补丁系列。
Git附带的示例sendemail-validate钩子检查所有已发送的补丁（不包括封面信）是否可以在上游存储库默认分支之上应用而不产生冲突。留下了一些占位符，以便在应用给定系列的所有补丁之后执行其他验证步骤。
在 Git 2.41 (Q2 2023) 中， "git send-email"(man) 学会了通过从命令行传递额外参数来将电子邮件头部提供给验证钩子。
none)完成。gitster --在提交 b6e9521中合并，2023年5月10日）
send-email：将头信息暴露给git-send-email的sendemail-validate钩子Cc：Luben Tuikov
Cc：Junio C Hamano
Cc：Ævar Arnfjörð Bjarmason
Acked-by：Luben Tuikov
Signed-off-by：Michael Strawbridge
git-send-email(man) 所要发送的电子邮件的 SMTP 标头信息作为第二个参数传递到 sendemail-validate 钩子中。githooks 已经包含在其 man page 中：git send-email调用。git send-email在发送任何电子邮件之前中止。
git来跟踪代码变更？你知道如何生成补丁吗？你已经尝试过什么了，现有文档的哪些部分是不足的？ - undefined