git-workflow

Git 工作流纪律

适用于：所有会改动代码的开发任务的完整生命周期。

0. 触发与跳过

TRIGGER：开始改动代码的工作 / 提到开分支 / 要求 commit / push / 开 PR / PR 合并后清理。 SKIP：纯咨询/阅读、极小打字纠错。

---

1. 分支策略

• 禁止在 main 直接提交
• worktree 用于隔离并行工作：从 main 拉一棵 worktree，与当前分支互不打断。工作树必须与当前 repo 物理隔离：统一集中到 ~/.bb-spec/worktrees/ 下管理，禁止嵌套在当前 repo 工作目录内（避免污染主仓库、被误 add / commit）

开始任务前必查

git branch --show-current        # 当前在哪个分支
git status --short               # 工作区是否有未提交改动

开新任务一律询问开分支方式

开任何新任务前，用 AskUserQuestion 让用户选开分支方式，默认 worktree：

• worktree（默认） → 从 main 新建隔离 worktree 并行，不切换、不打断、不污染当前分支

  git worktree add ~/.bb-spec/worktrees/<repo>-<branch> -b <branch> main
  

• 直接切分支 → 在当前 repo 直接从 main 创建新分支开始工作（要求当前工作区干净）

  git pull && git switch -c <branch>
  

唯一例外（不问）：本次是延续当前分支的同一任务（不是开新活儿）→ 直接在当前分支继续，既不新建 worktree 也不切分支。无法判断是延续还是新任务时，照常 AskUserQuestion 询问。

多 repo 工作区（go.work / pnpm-workspace / Cargo / Gradle composite 等）

当项目由多个 repo 组成、且构建靠相对路径跨 repo 引用（如 go.work 的 ./service-a、pnpm-workspace.yaml、Cargo workspace 的 path = "../lib"、Gradle composite build）时：

• 禁止只对单个成员 repo 拉 worktree——会打散工作区的相对布局，./service-b 这类引用指空，整个 workspace 解析失败。

• 禁止用整目录复制替代 worktree——放弃隔离与一键清理、磁盘翻倍、副本易 drift。

• 正确做法：建一个统一父目录（普通目录、非 repo），对每个参与 workspace 的成员 repo 各拉一棵 worktree 到该父目录下，复原原有相对布局。每个 repo 仍是真 worktree（改动可追踪、可独立 commit/push、与主仓库共享对象、git worktree remove 一键清理）。

  mkdir -p ~/.bb-spec/worktrees/<project>-<branch>
  git -C <repo-root>/service-a worktree add ~/.bb-spec/worktrees/<project>-<branch>/service-a -b <branch> main
  git -C <repo-root>/service-b worktree add ~/.bb-spec/worktrees/<project>-<branch>/service-b -b <branch> main
  

• 工作区根文件（go.work / pnpm-workspace.yaml 等）位于非 repo 的容器层、不被任何 git 跟踪，拉 worktree 时不会自动带过来——需手动放一份到统一父目录（相对路径原样可用，无需改）。

• 清理对称：各成员 repo 各自 git worktree remove，统一父目录手动删。

---

2. 阶段性本地 commit

• 每完成一个可独立验证的子任务 → git commit（本地）
• commit message 遵循仓库历史风格（先 git log --oneline -20 看一眼）
• 禁止阶段性 commit 后立即 push（本地未推时可 amend/rebase 修正）
• 任务队列还有待办 → commit 后直接继续，不中断询问

---

3. 推送门槛

仅当满足所有条件才进入推送：功能本地全部完成 + 所有测试通过 + 用户确认。

多 PR 依赖关系

有依赖 → 按顺序逐个 push + 开 PR，前一个合并后再推下一个。 无依赖 → 可并行推送，但仍需本地验证完成后统一开始。

---

4. PR 描述（六段式，整体 ≤ 50 行）

## 背景
当前状态、相关模块、为什么现在做。

## 需求
具体动因、要解决的问题、不做的代价。

## 方案
实际改动点、范围边界、影响面。

## 结果
改动后的行为变化、用户可感知的差异。

## 测试
验证方式、覆盖场景。

## 规范
遵循或涉及的规范（无 spec 时写"无"）。

reviewer 不跳转 issue 也能完整理解。禁止：只一行 What / 仅链接 issue / 仅粘贴 commit。

---

5. 按需建 issue（默认不建）

建的场景：跨多 PR 长周期追踪 / 暂不实施的 bug 记录 / 外部 triage。 issue 正文包含背景、需求、方案。PR 关联 issue 时顶部写 Closes #<num>。

---

6. 合并后清理

git checkout main && git pull origin main
git rev-parse --abbrev-ref HEAD           # 确认在 main
git branch -D <branch>                    # squash merge 后 -d 会拒绝
# 探测远程分支是否存在再删
git ls-remote --exit-code --heads origin <branch> && git push origin --delete <branch>
git fetch -p                              # 裁剪远程引用