Question

我遇到的一个常见情况是，开发人员提交了一个拉取请求，审阅者随后发表了一些评论，开发人员修复了问题，然后使用git rebase更新了原始提交，因此将来更容易阅读历史记录。现在的问题是，似乎看不到原始提交和添加到提交中的新更改之间发生了什么变化。

这使得审查代码变得困难，因为无法查看新的更改是否解决了所提出的问题，或者无法进行其他导致新问题的更改，因此必须再次审查整个PR或盲目接受。

git是否提供工具来查看由重定基础引起的更改，或者有替代的工作流程，允许git历史记录每个更改包含一次提交，而无需额外的“固定”提交，但仍允许审阅者查看代码中的每个更改。公关阶段。对于上下文，我正在使用bitbucket，但是如果原始git或其他网站可以做到这一点，我将很感兴趣。

Answer 1

没有本机（GitHub，BitBucket或GitLab）解决方案。

GitHub PR保留了对旧历史的引用（在每次重新设置基准之前），但是将旧历史与新历史进行比较太麻烦了。

另一种选择是鼓励开发人员重新设定历史记录/澄清历史记录：

仅在审核过程的末接受最终评估，然后接受PR。
不是在审核过程中，否则会出现OP的问题所表达的问题。

Answer 2

所以我希望我能理解您的描述。据我了解，基本上，在审阅者对pull-request（PR）发表评论之后，开发人员会更新所述提交，然后在推送之后，您仍然只会看到一个提交（其中是新提交，之后又更新一次）修复程序，并且原始提交为“ gone”）。是？

如果是这样，我建议您更新您的工作流程。就像在原始提交之后提交修订一样简单。无需重新设置/更改历史记录，因为它仍然可读。

develop   o---o---o
                   \
feature             A

然后假设A是原始提交，现在用于PR，而审阅者则对A进行审核。开发人员要做的下一件事就是简单地在A之后提交：

develop   o---o---o
                   \
feature             A---A'

在审阅者评论后，以A'作为“解决方案”。您可以通过调用以下方法检查从A'到A的增量：

git diff hashidAprime hashidA

我建议仅在从develop / trunk更新时才重新分支。仍在工作时请勿重新设置基准。现在，如果您被那种工作流程“困住了”，在该工作流程中您严格要求在PR之前对每个功能进行一次提交，那么我建议您每次进行修复时，都只需在提交消息中加以注释即可。如果可能的话，一种变更日志。但这只会显示已更改内容的描述，而不会显示受影响的代码块。每次进行审查时，我个人都会选择仅提交和提交。它看起来仍然很整洁，如果您问我，您实际上不必严格要求一次提交。

保持git历史记录整洁，同时保留更改日志以供代码检查

2 个答案: