我对GitHub没有答案。
人们有时使用补丁系列（通过电子邮件）工作流[1]的做法是，在初始审查之后，为每一轮审查提供git-range-diff（1）的输出。更具体地说，这意味着您将分支的状态存储为轻量级标记（存储初始的“版本1”，在发送时存储“版本2”，等等）。你可以使用这个命令：

git range-diff main feature-v1 feature-v2

它们还描述了每个系列版本与前一个版本的不同之处。
例如，在本补丁系列中，作者将当前版本描述为：

Changes since v6[3]:

 * Glen pointed out that ejecting a commit in v6 orphaned a
   corresponding forward-reference in a commit message, fix that.

range-diff表示这是唯一的变化：

Range-diff against v6:
 1:  43fdb0cf50c =  1:  9f297a35e14 config tests: cover blind spots in git_die_config() tests
 2:  4b0799090c9 =  2:  45d483066ef config tests: add "NULL" tests for *_get_value_multi()
 3:  62fe2f04e71 !  3:  a977b7b188f config API: add and use a "git_config_get()" family of functions
    @@ Commit message
         "int" instead of "void". Let's leave that for now, and focus on
         the *_get_*() functions.

    -    In a subsequent commit we'll fix the other *_get_*() functions to so
    -    that they'll ferry our underlying "ret" along, rather than normalizing
    -    it to a "return 1". But as an intermediate step to that we'll need to
    -    fix git_configset_get_value_multi() to return "int", and that change
    -    itself is smaller because of this change to migrate some callers away
    -    from the *_value_multi() API.
    -
         1. 3c8687a73ee (add `config_set` API for caching config-like files, 2014-07-28)
         2. https://lore.kernel.org/git/xmqqczadkq9f.fsf@gitster.g/
         3. 1e8697b5c4e (submodule--helper: check repo{_submodule,}_init()
 4:  e36303f4d3d =  4:  3a5a323cd91 versioncmp.c: refactor config reading next commit

如何在GitHub等forge上使用

就像我说的，我没有GitHub特定的答案。因此，这将是非正式/手动程序。

• 进行初始PR
• 创建标签<branch-name>-v1
• 也推送这些标记，以便审阅者可以使用它们
• 可选：创建一个带注解的标记，并将系列版本描述存储在标记消息中
• 根据反馈改变你的分支（重写）
• 创建一个标记<branch-name>-v2并强制推送更改
• 更新PR描述，以提及当前版本以及与前一版本的差异
• 如果您合并了可选步骤，则“differences”部分将与注解标记中的部分相同
• 重复直到完成

注意事项

1.使用git format-patch和git send-email发送提议的变更以供审查。首先，您发送初始系列，即“版本1”。然后，当讨论结束后，你根据反馈发送一个“版本2”，依此类推，直到它被任何你想包含你的更改的人包含在内。