假设乔正在处理一项大任务。他在一个大型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中版本差异的捕获,对于那些不知道我在说什么的人。
提前感谢您的任何建议!
1条答案
按热度按时间h5qlskok1#
我对GitHub没有答案。
人们有时使用补丁系列(通过电子邮件)工作流[1]的做法是,在初始审查之后,为每一轮审查提供git-range-diff(1)的输出。更具体地说,这意味着您将分支的状态存储为轻量级标记(存储初始的“版本1”,在发送时存储“版本2”,等等)。你可以使用这个命令:
它们还描述了每个系列版本与前一个版本的不同之处。
例如,在本补丁系列中,作者将当前版本描述为:
range-diff表示这是唯一的变化:
如何在GitHub等forge上使用
就像我说的,我没有GitHub特定的答案。因此,这将是非正式/手动程序。
<branch-name>-v1
<branch-name>-v2
并强制推送更改注意事项
1.使用
git format-patch
和git send-email
发送提议的变更以供审查。首先,您发送初始系列,即“版本1”。然后,当讨论结束后,你根据反馈发送一个“版本2”,依此类推,直到它被任何你想包含你的更改的人包含在内。