如何审查拉取请求修订？

Question

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

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

我以前用过Phabricator，它会跟踪PR的每一次修订，这样你就可以diff不同修订之间的变化，漂亮地解决这个问题（https://secure.phabricator.com/D13641?vs =32966&id=32967#toc）。例如，它可以让您比较修订版 1 和修订版 2 的更改）。这样，您就可以只专注于审查少数新更改，而不是 20 次提交。

有没有办法可以用 Github 完成类似的事情？我想有一个我们不知道的不同工作流程。如果没有，人们有没有 github 的替代品？ （除了 Phabricator？）。

我能想到的唯一选择是不修改提交，而是创建新提交而不是强制推送。这样做的问题是提交历史变得非常混乱，并且会在以后的提交中修复带有错误的提交。

在下面附上 Phabricator 中修订差异的捕获，以供那些不知道我在说什么的人使用。

提前感谢您的任何建议！

Answer 1

我没有 GitHub 的答案。

人们有时使用补丁系列（通过电子邮件）工作流程[1]做的是 他们为每一轮提供 git-range-diff(1) 的输出 第一次之后复习。更具体地说，这意味着你 将分支的状态存储为轻量级标签（存储初始 “version 1”，发送时存储“version 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/[email protected]/
         3. 1e8697b5c4e (submodule--helper: check repo{_submodule,}_init()
 4:  e36303f4d3d =  4:  3a5a323cd91 versioncmp.c: refactor config reading next commit

如何在 GitHub 之类的 Forge 上使用它

就像我说的，我没有特定于 GitHub 的答案。所以这一切都会 非正式/手动程序。

• 做初始公关
• 制作标签

  <branch-name>-v1

  • 也推送这些标签，以便评论者可以使用它们
  • 可选：制作一个带注释的标签并存储系列版本 标签消息中的描述
• 根据反馈更改您的分支（重写）
• 制作标签

  <branch-name>-v2

  并强制推送更改
• 更新 PR 描述以提及当前版本和 与前一个的区别
  • “差异”部分将与注释中的相同 如果您合并了该可选步骤
  ，请标记
• 重复直到完成

注意事项

1. 你在哪里使用

   git format-patch

   和

   git send-email

   发送 提议的修改以供审查。首先你发出一个初始系列，一个 “版本 1”。然后当讨论完之后你发出一个 基于该反馈的“版本 2”，依此类推，直到它被包含在内 由任何你想包含你的更改的人。