您可以尝试挑选更改，最简单的方法是使用下载命令。这将导致类似如下的结果：
这里我假设A =变化9642和B = 9643

git reset --hard origin/main
# fetch change A
git fetch ssh://USER@example.com:29418/project refs/changes/42/9642/1 && git cherry-pick FETCH_HEAD
git push origin HEAD:refs/for/main

git reset --hard origin/main
# Fetch change B
git fetch ssh://USER@example.com:29418/project refs/changes/42/9643/1 && git cherry-pick FETCH_HEAD
git push origin HEAD:refs/for/main

你做得对，变更A和变更B之间确实还有关系！
当你发送B rebased on origin/main的提交并将其发送回Gerrit时，它会检查接收到的提交是否存在具有相同(project, branch, Change-Id)的预先存在的更改。如果存在，Gerrit会将你的新提交作为新补丁集附加到同一个更改。
再次查看您的示例，但这次将补丁程序集编号附加到更改A和B，您已经从以下内容开始：

main -- A,1 -- B,1

在Web UI中查看****A或B时，可以看到关系链：

B
A

然后在本地将B重定基到main上，您的本地存储库具有：

main -- A -- B
    \-- B (rebased)

当发送B (rebased)时，Gerrit将其作为第二个补丁集附加到B的更改中。

main -- A,1 -- B,1
     \-- B,2

查看A时，Web UI显示：

B (not current)
A

这是因为A仍有后续更改，即补丁程序集B，1。
当转到B,2时，您将不会再看到与A的关系，因为您已将其重定基。
一旦B,2被合并，Gerrit就会检测到它，当查看A时，我认为它会显示：

B (merged)
A

您可以修改A并将其发回复查。这将创建一个新的补丁程序集，该补丁程序集未附加到B。在Gerrit端，资料档案库将如下所示：

main -- A,1 -- B,1  (original chain, now obsolete)
    \-- B,2
    \-- A,2