Appearance
开发工作"做完"和"安全收尾"不是同一件事。安全收尾的核心流程只有三步：验证测试通过 → 明确选择后续方式（合并/PR/保留/丢弃）→ 清理工作区。跳过任何一步都可能留下隐患——带着失败测试合并、遗留大量孤立分支、或者意外删掉还没推送的提交。本文把这套流程拆开讲清楚，帮你在每个分支收尾时都能踩实每一步。
finishing-a-development-branch：开发完成后怎么安全收尾
很多人在功能开发完成后的操作是"感觉差不多了，直接合进去"。问题就藏在这个"感觉"里：测试真的全过了吗？分支历史清楚吗？worktree 还挂在那里没清？这些细节积累起来，就是日后难以定位的技术债。
finishing-a-development-branch 这个 skill 把收尾过程标准化为四步，确保每次交付都可验证、可追溯、工作区干净。
第一步：先跑测试，不通过就停下
在做任何收尾决策之前，必须先把项目的测试套件跑一遍。
bash
# 根据项目技术栈选对应命令
npm test
cargo test
pytest
go test ./...如果有测试失败，不进入下一步。把失败清单列出来，先修复，再重新跑一遍确认全绿。带着失败测试合并只是在给自己埋雷——后来的人不知道这是"预期失败"还是新引入的问题。
只有全部测试通过，才继续往下走。
第二步：确认基础分支
在选择收尾方式前，需要知道当前分支是从哪里拉出来的。
bash
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null如果项目有其他约定（比如从 develop 分支），直接确认一下即可。基础分支搞错了，后续合并或 PR 的目标就会出问题。
第三步：选择收尾方式
测试全过之后，有四种选择，每种对应不同的场景和后续操作。
选项 1：本地合并回基础分支
适合：个人项目、不需要 code review 的小改动、或者只是在本地整理分支。
bash
git checkout main # 切回基础分支
git pull # 拉最新
git merge feature-branch # 合并
# 合并后再跑一次测试，确认合并结果没有引入新问题
git branch -d feature-branch # 删除已合并的分支合并后的测试验证是关键——两个分支分别测试通过，合并结果不一定通过。
选项 2：推送并创建 Pull Request
适合：团队项目、需要 review、或者想通过 CI 再验证一遍。
bash
git push -u origin feature-branch
gh pr create --title "feat: ..." --body "$(cat <<'EOF'
## Summary
- 改动点 1
- 改动点 2
## Test Plan
- [ ] 验证步骤 1
- [ ] 验证步骤 2
EOF
)"PR 描述写清楚"改了什么"和"怎么验证"，review 的人才能高效给出反馈。
这个选项不删除本地分支，也不清理 worktree——PR 合并之前分支还需要保留。
选项 3：暂时保留，稍后处理
适合：工作还没做完、需要等待外部依赖、或者想先切去做别的事。
直接结束当前工作，不做任何合并或删除操作。worktree 也保留原样。
唯一的要求是：知道这个分支在哪，以及为什么保留。不然几周后回来，自己都不记得这个分支是干什么的。
选项 4：丢弃这次工作
适合：方向走错了、需求变了、这只是一次探索性尝试。
丢弃操作不可逆，必须先确认。 确认前需要列出：
- 分支名称
- 所有提交记录（
git log --oneline） - worktree 路径
确认无误后再执行：
bash
git checkout main
git branch -D feature-branch # 大写 D 是强制删除第四步：清理 worktree
使用了 git worktree 的场景，收尾时需要一并清理。
先检查当前分支是否有 worktree：
bash
git worktree list | grep $(git branch --show-current)如果有，根据选择决定是否清理：
| 收尾方式 | worktree 处理 |
|---|---|
| 本地合并（选项 1） | 清理 |
| 创建 PR（选项 2） | 保留（PR 还在） |
| 暂时保留（选项 3） | 保留 |
| 丢弃（选项 4） | 清理 |
bash
# 清理时执行
git worktree remove <worktree-path>为什么这套流程是必要的
不跑测试就合并——最常见的问题。功能在本地手动试过没问题，但没跑自动化测试，合并后 CI 挂了，定位成本远高于提前验证的成本。
给四个选项，而不是问"接下来怎么办"——开放式问题容易让人陷入犹豫或遗漏选项。四个具体选项覆盖了所有常见场景，做决定更快。
丢弃前要求明确确认——强制写出"放弃什么"，避免手误删掉还没推送的重要工作。
选项 2/3 不清理 worktree——PR 还在审阅中，或者工作还要继续，这时候删 worktree 会打断工作流。
快速参考
| 选项 | 合并到本地 | 推送/PR | 保留 worktree | 删除分支 |
|---|---|---|---|---|
| 1. 本地合并 | 是 | - | 否 | 是（正常删除） |
| 2. 创建 PR | - | 是 | 是 | 否 |
| 3. 暂时保留 | - | - | 是 | 否 |
| 4. 丢弃 | - | - | 否 | 是（强制删除） |
FAQ
Q: 测试跑了很久，可以先合并再看结果吗？
A: 不建议。测试跑慢是另一个需要解决的问题，但跑慢不能成为跳过验证的理由。可以用 --testPathPattern 之类的参数先跑相关测试子集，确认核心路径没问题后再等完整结果。
Q: 选项 2 创建了 PR，PR 合并之后怎么清理？
A: PR 合并后，远端分支通常会被自动删除（取决于仓库配置）。本地分支可以用 git branch -d feature-branch 删除，worktree 也可以在 PR 合并后一并清理。
Q: 选项 4 丢弃后发现其实不该丢，能找回来吗？
A: 如果分支已推送过，可以从远端找回。如果只在本地，git reflog 可以看到被删除的提交哈希，用 git checkout -b 新分支名 <commit-hash> 恢复。但这是应急操作，不是常规手段——丢弃前的确认环节就是为了避免这种情况。
Q: 这套流程和 CI/CD 冲突吗？
A: 不冲突，而是互补。本地测试验证的是"代码在本机能跑通"，CI 验证的是"在干净环境、标准配置下也能跑通"。两个都要。