把大型 PR 拆成小 commit 的实用技巧：用 AI 重新切片代码变更
Neat trick to make big PRs readable: reslicing them into small commits
面对 AI 生成的 +4k/-1k、涉及 72 个文件的大型 PR，作者尝试用 AI 将其重新拆分成约 20 个聚焦单一改动的 commit，使审查变得轻松许多。每个 commit 无需独立编译或通过测试，只需讲清整体变更故事的一个章节。作者已将这一做法固化为一项技能，并计划今后每次审查大型 PR 时都使用。
审查一个 +4k/-1k 变更集、涉及 72 个文件的 PR 相当困难。这样的 PR 过去很少见，也许只有在需要一次性进行大规模重构或升级时才会出现。但现在我经常遇到它们。
上周，当 AI 为我写了两个这样的 PR 而我不得不审查它们时，我决定尝试一个新技巧。
嗯，这个技巧其实很老；大约七年前，当我开始在 Vena Solutions 担任 Tech Lead 时，我第一次见到它。那时，我们的架构副总裁非常喜欢重构和清理，这经常产生大型 PR。为了让这些 PR 对我们来说更容易接受，他把它们组织成整齐、非常专注的单个提交，每个提交只包含一个特定的更改，就像这样：
有些提交改了很多行，但每一行都是同样的更改（例如将 SomeThing 重命名为 OtherThing）。其他提交则有特定的狭窄焦点，比如对复杂算法的微调。每个单独的提交不必自身可编译或通过测试；它只需要讲述 PR 整体故事中的下一章。
这就是我尝试的新技巧：让 AI 对已有的 PR 做这件事。
我自己绝不会手动做这件事。但 AI 有无限的耐心（好吧，只要 token 够用），它毫无问题地拆解了全部 4k 行代码，并仔细地将它们拼凑成大约 20 个提交。它并不完美，但已经足够好，审查起来容易多了。
于是我就把它变成了一个技能（见下文）；在又用了几个 PR 之后，我想从现在起我每次都会这么做，这样我才能自己读懂这些 PR。
如果你不熟悉堆叠 PR，这个 GitHub 页面给出了不错的概述。
它们当然是一种选择，但我发现，在开始实现之前，并不总是清楚哪个 PR 应该是基础 PR，而且有时在大量修复和后续调整之后，堆叠需要大量重新组织，当你处理的是 PR 而不是提交时，这很烦人。
而且，把一个 4k 行的 PR 重新切成 20 个提交，比切成 20 个堆叠 PR 要实用得多。
来源：Hacker News · i-kh.net