split-to-prs · git:20260817.d4dfa41 · 2026-08-17 · sha256 d948f5c77ffd98ec
split-to-prs git:20260817.d4dfa41A
Immutable. This exact content is served forever at /api/v1/blob/d948f5c77ffd98ec.
--- name: split-to-prs description: 把一堆改动拆成几个各自能审的小 PR 时用。先提拆分方案、经用户确认才动 git;动手前先做不碰工作区的可恢复快照,只暂存计划内的文件。 --- # 拆成小 PR 一堆混在一起的工作(脏工作区、一条大分支、或一个巨型 PR),拆成 几个审得动的小 PR。 `[约束]` 两条硬规则,整个流程都压着: - **方案没经用户确认前,不建分支、不提交、不推送、不开 PR。** - **不销毁用户的工作。** `reset --hard`、`clean -fdx`、删分支、 force-push 一律不做,除非用户明说。 ## 1. 看清现状 对比默认分支,把**已提交的和未提交的**都算进来: ```bash git status --short git log --oneline origin/HEAD..HEAD git diff --stat origin/HEAD...HEAD ``` 从改动本身和对话历史里恢复意图:这堆工作实际包含几件事。 ## 2. 提方案 切分的判据,按优先级: - **一个 PR 一句话说得清**——标题写不出来的切片是切错了; - **审阅人边界**:有 `CODEOWNERS` 之类的就先看,不同 owner 的 改动别混在一个 PR 里; - 耦合紧的留在一起,别为了小而把一次接口改动和它的调用方拆开 ——那样每个 PR 单独都跑不过 CI。 默认从默认分支各切各的、互相独立;只有依赖是真实的(B 编译依赖 A 的新接口)才叠 stack,并在方案里说明合并顺序。 方案给用户看:每片一个 PR 标题,标题说不清的补一行范围说明。 **等确认。** ## 3. 执行 工作区有未提交的东西时,先做快照——`stash create` 只创建对象 不动工作区,比 `git stash` 安全: ```bash SHA=$(git stash create "pre-split") [ -n "$SHA" ] && git update-ref "refs/backup/pre-split-$(date +%s)" "$SHA" ``` 然后逐片来:从正确的基底建分支,**只暂存这一片计划内的文件** (禁 `git add -A` / `git add .`),提交、推送、开 PR。`gh` 不可用 或没登录时,推完分支把「怎么手动开 PR」告诉用户,不要卡死在这一步。 ## 4. 汇报 每个 PR 的标题和链接;起始分支/工作区还剩什么;备份 ref 的名字。 备份和原分支**留着**,用户说删才删。