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 的名字。
备份和原分支**留着**,用户说删才删。