我遇到的一个常见情况是开发人员提交了一个拉取请求，审阅者然后做了一些 cmets，开发人员修复了问题，然后使用 git rebase 更新原始提交，以便将来更容易阅读历史.现在的问题是似乎不可能看到原始提交和添加到提交中的新更改之间发生了什么变化。
这使得审查代码变得困难，因为无法查看新更改是否解决了提出的问题，或者是否进行了其他更改导致新问题，因此必须再次审查整个 PR 或盲目接受。
git 是否提供工具来查看由变基引起的更改，或者是否有替代工作流程允许 git 历史记录包含每次更改的单个提交，而无需额外的“修复”提交，但仍允许审阅者查看每个更改，因为代码在公关阶段。对于上下文，我使用的是 bitbucket，但如果原始 git 或其他网站可以做到这一点，我会很感兴趣。
【问题讨论】：
没有本地（GitHub、BitBucket 或 GitLab）解决方案。
GitHub PR 保留对旧历史的引用（在每次变基之前），但是比较旧历史和新历史太麻烦了。
替代方法是鼓励开发人员重新定义/澄清历史：
【讨论】：
所以我希望我能理解你刚才描述的内容。据我了解，基本上在审阅者在拉取请求（PR）上发布 cmets 之后，开发人员更新所述提交，然后在它被推送后，您仍然只会看到一个提交（其中它是新的和更新后的修复，原始提交已“消失”）。是的？
如果是这样，我建议您更新您的工作流程。这就像在原始提交之后提交修复一样简单。无需重新设置/更改历史记录，因为这仍然是可读的。
develop o---o---o
\
feature A
然后假设 A 是原始提交，现在用于 PR，并且审阅者审查提交 A。开发人员要做的下一步就是在 A 之后提交：
develop o---o---o
\
feature A---A'
A' 是审阅者评论后的“修复”。您可以通过调用检查从 A' 到 A 的增量：
git diff hashidAprime hashidA
我建议仅在从开发/主干更新时重新设置分支。当你还在工作时不要变基。现在，如果您被那种工作流程“困住”了，在 PR 之前，您严格来说每个功能只有一次提交，那么我建议您每次进行修复时，只需在提交消息中注明即可。如果可以的话，有点像变更日志。但这只会显示对已更改内容的描述，而不是受影响的代码块。每次有评论时，我个人都会选择提交和提交。它仍然看起来很整洁，如果你问我，你真的不需要严格执行一次提交。
【讨论】：