git 如何查看拉式请求修订版?

kmb7vmvb  于 2023-05-12  发布在  Git
关注(0)|答案(1)|浏览(153)

假设乔正在处理一项大任务。他在一个大型PR中提交了他的工作的初始修订,其中有20个提交。现在,其他开发人员花了很长时间审查PR,并要求进行一些更改/修复。Joe现在用请求的更改修改他的提交,并(强制)推送PR的新修订版。
现在,审阅者需要从头开始重新审阅整个内容,即使新的更改非常小。我还没有找到处理这个问题的方法。
在过去,我使用过Phabricator,它可以跟踪PR的每个修订,这样你就可以在不同的修订之间区分更改,并漂亮地解决这个问题(https://secure.phabricator.com/D13641?vs=32966&id=32967#toc)。例如,它允许您比较修订版1和修订版2的更改。这样,您就可以只关注于查看少数几个新更改,而不是20个提交。
有没有一种方法可以用Github实现类似的功能?我想有一个不同的工作流程,我们不知道。如果没有,人们是否有Github的替代品?除了Phabricator?).
我能想到的唯一替代方案是不修改提交,而是创建新的提交,而不是强制推送。这样做的问题是提交历史会变得非常混乱,并且会有带有bug的提交,这些bug会在以后的提交中得到修复。
下面附上Phabricator中版本差异的捕获,对于那些不知道我在说什么的人。
提前感谢您的任何建议!

h5qlskok

h5qlskok1#

我对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-patchgit send-email发送提议的变更以供审查。首先,您发送初始系列,即“版本1”。然后,当讨论结束后,你根据反馈发送一个“版本2”,依此类推,直到它被任何你想包含你的更改的人包含在内。

相关问题