如何审查拉取请求的修订？

Question

假设Joe正在处理一个大任务。他在一个包含20个提交的大PR中提交了他的工作的初始修订版。现在其他开发人员花费很长时间审查该PR，并要求进行一些更改/修复。现在，Joe使用所请求的更改修改了他的提交并（强制）推送了PR的新修订版。

现在，即使新更改非常小，审阅者也需要从头开始重新审查整个内容。我没有找到解决这个问题的方法。

过去，我使用过Phabricator，它跟踪PR的每个修订版本，以便您可以在不同修订版本之间进行差异比较，并美观地解决了这个问题（https://secure.phabricator.com/D13641?vs=32966&id=32967#toc）。例如，它允许您将第1个修订版与第2个修订版的更改进行比较。这样，您只需关注审核少量新更改，而不是20个提交。

有没有办法在Github上实现类似的东西？我想象中有一种我们不知道的不同工作流程。如果没有，人们有没有除Phabricator之外的替代方案？

我能想到的唯一替代方案是不修改提交，而是创建新的提交并且不进行强制推送。但这样会导致提交历史非常混乱，并且会有已在后续提交中修复的错误提交。

以下是 Phabricator 中的修订差异截图，供那些不了解我所说内容的人参考。

感谢您提前给予的任何建议！

- Juan

---

我认为GitHub允许您查看自您上次审查以来的差异。 - eftshift0

GitHub曾在其公共路线图上为此问题设置了问题，但最近已将其删除。不知道为什么，这是他们的代码审查系统中缺失的一个重要组件。 - 9999years

Answer 1

我没有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 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的平台上使用

就像我说的，我没有GitHub特定的答案。所以这将是一种非正式/手动的过程。

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

注意事项

1. 当你使用git format-patch和git send-email发送建议性的更改以供审查时，你需要注意以下几点。首先，你需要发送一个初始系列，即“版本1”。然后，在讨论了该版本之后，你可以根据反馈意见发送“版本2”，以此类推，直到你想要包含更改的人将其纳入。

- Guildenstern