在$dayjob审查所谓的Pull Requests

# 关于在$dayjob审查所谓的Pull Requests 来源：https://rkta.de/dayjob-pr-review.html ## Rene Kita 的博客 博客 (https://rkta.de/index.html)关于 (https://rkta.de/about.html)RSS (https://rkta.de/feed.xml)链接 (https://rkta.de/links.html)代码 (https://git.rkta.de/)2026-01-14过去三年里，我在$dayjob花费了大量时间融入客户的团队。他们使用一款可爱的微软产品来托管Git仓库，并通过所谓的“拉取请求”（PR）#0 (https://rkta.de/dayjob-pr-review.html#0) 将更改合并到master分支。不出所料，这款微软产品的PR审查界面极其糟糕。另一个问题是，与所有基于Web的审查界面一样，在初次审查之后的迭代审查体验也很糟糕。 假设我创建了一个PR并收到了第一轮反馈，比如我在某个提交中留下了一些小瑕疵或失误。作为一位好公民 (https://sethrobertson.github.io/GitBestPractices/#sausage)，我不会创建新的提交来修复这些问题，而是将这些修复归并到本应完成该提交的那个提交中。对于传统的基于邮件的流程，我会等待一段时间收集所有反馈，修正所有提交，然后发送v2版本。而对于这些基于Web的流程，我需要创建另一个PR，或者通过强制推送来替换之前的版本。强制推送后，之前的版本就消失了，作为审查者，我必须重新审查整个补丁集。 每当被指派审查某个PR时，我通常会以以下方式规避这些缺陷，前提是我的同事想要合并origin/feature分支，并且在修改提交后进行了强制推送#1 (https://rkta.de/dayjob-pr-review.html#1)： 1. 从远程创建分支：`git checkout -b v1 origin/feature` 2. 审查提交：`git log -p --reverse origin/master..` 3. 提供反馈，等待同事修复 4. 拉取并从远程创建分支：`git fetch; git checkout -b v2 origin/feature` 现在，我有了v1和v2版本，就像传统流程中那样，然后可以使用git-range-diff(1)比较两个修订版本：`git range-diff origin/master..v1 origin/master..` 如果提交乱七八糟（在$dayjob我们允许在合并时压缩提交），我会使用`git diff origin/master`来代替上面`git log -p --reverse`这一步。对于补丁审查步骤（使用`git log -p --reverse`），我通常粗略浏览所有提交。如果我想添加超过一两条的评论，通常会把日志通过管道导入编辑器，以便在阅读更改时添加评论： ``` git log -p --reverse origin/master.. | sed 's/^/> /' | vim -c 'set filetype=mail' - ``` 审查完成后，我只需将评论复制到Web界面中——这仍然很烦人，但稍好一些。 --0: 这个过程里并没有“拉取”（pull）操作…… 1: 如果他们创建了新的PR，同样的方法也适用，只需将v2基于新PR的分支即可。 最后修改时间：2026-01-14T23:15:04Z ---