docs: add git worktree (create & delete) to AI-maintained tech notes

[gh-pr-review]

变更内容

在 AI 维护的技术随笔中新增 ## Git 章节，下辖 ### git worktree —— 不干扰当前工作目录切分支的正解，系统整理 worktree 的创建与删除。

知识点源自 PR #1536 评论区讨论：

• 场景 —— 主工作区有未提交内容、又要切到冲突 PR 分支
• 创建 worktree 的三种等价做法对比（分支名 / pull/<N>/head / 远端 ref）
• git fetch origin 的范围与收窄技巧（--depth=1 / --no-tags / --prune）
• 术语澄清 —— worktree / main worktree / linked worktree
• 删除流程 —— git worktree remove → git branch -d → git push origin --delete → git fetch --prune
• 目录自动删除边界（干净 / 未追踪 / 手动 rm -rf / 权限失败）
• 常见坑：顺序、孤儿 worktree、同分支双检出、git worktree list 排障

相关

• 来源：docs: add macOS sips 命令详解 to AI-maintained tech notes #1536

[LetMeFly666]

@gh-pr-review (reviewer) /new 参考本地/lets-gh-review skill review #1548

[Tisfy]

PR Review — #1548 docs: add git worktree (create & delete) to AI-maintained tech notes

PR 概要

本次 PR 在 Solutions/Other-AI-LLM_Maintained_TechNotes.md 的技术随笔中新增 ## Git 章节，系统整理 git worktree 的 创建 / 删除 / 术语 / 常见坑。内容源自 PR #1536 的评论区讨论，+68 / -0，单文件改动，不涉及代码逻辑，属于纯文档追加。

代码正确性分析

文件	变更类型	正确性	说明
Solutions/Other-AI-LLM_Maintained_TechNotes.md	追加章节	✅ 技术描述总体准确	创建/删除命令、术语、边界情形均对；少量表述可进一步严谨

潜在问题与建议

P2 — 方式 B 示例里硬编码了 1536，与方式 A / C 的 feat/xxx/yyy 占位符不一致
方式 A 使用 feat/xxx/yyy 作为"任意分支名"占位符，读者一看便知是需要替换的占位。但方式 B 突然出现 pull/1536/head:pr-1536，1536 是 PR #1536（本 PR 知识点来源的那条 PR 的编号），会让读者误以为这个数字有特殊含义，或以为只能用于某个具体 PR。建议统一用 <N> 占位符，与上文的 <主仓库目录>、下文的 :local-name 风格一致。

P2 — git branch -d 在 squash-merge 场景会失败，应补充说明
第 270 行注释写"merge 过用 -d，未 merge 用 -D"。但 GitHub 上最常见的合并方式之一是 Squash & Merge——合并后 master 上的提交 SHA 与本地分支 tip 完全不同，git branch -d 检查不到"merged into upstream"，会拒绝删除并要求 -D。这是 worktree 清理流程中非常高频的真实坑（尤其是本仓库 PR 大量走 squash），文档里若不提醒，读者实操时第一次就会踩到。建议把注释里的条件加一条。

P3 — "目录已被手动 rm -rf" 行的处理建议可更精确
第 283 行说目录被手动 rm -rf 后 "改用 git worktree prune 清残留元信息"。实测中，新版 Git（≥ 2.17）里 git worktree remove <path> 对已被手动删除的目录会直接失败并提示使用 prune，这一点描述无误。但也可补一句"或直接 git worktree remove --force <path>"——某些 Git 版本下加 --force 也能清掉元信息，作为备选。此点属锦上添花，可不改。

P3 — "是只读 ref" 的表述稍口语
第 254 行表格里 "是只读 ref，需要 :local-name 才便于 push" 的"只读"严格说不准确：pull/<N>/head 是 server-side 特殊 ref，客户端 fetch 后拿到的是普通对象，只是 push 回 refs/pull/<N>/head 不被 GitHub 接受（必须 push 到源分支）。表述上可改成 "指向 PR head 的远端特殊 ref，不能直接 push 回去更新 PR"。此点非阻塞。

P3 — git fetch origin feat/xxx/yyy:feat/xxx/yyy 在本地分支已存在且分叉时会失败
方式 A 的一句话注释"只拉这一条 ref，最省带宽"准确，但没提示：若本地已有同名分支且与远端分叉，这条 fetch 会以 non-fast-forward 被拒绝，此时需 + 前缀（+feat/xxx/yyy:feat/xxx/yyy）强制更新或改用其他命令。对新手常见坑，可在"常见坑"段落加一条。非阻塞。

总结表格

维度	评级	说明
技术准确性	🟢 Good	核心命令、语义、清理流程均对
完整性	🟡 Fair	缺少 squash-merge 对 -d 的影响提醒；fetch 覆盖分叉分支未提
可读性	🟢 Good	结构清晰：场景 → 创建 → 术语 → 删除 → 坑
一致性	🟡 Fair	方式 B 示例用 1536 硬编码，与方式 A / C 的 xxx/yyy 占位不一致
风险	🟢 None	纯文档追加，不影响任何代码路径

最终合并建议

可合并 — 技术内容无误，属有价值的知识沉淀，且已在本轮互动中修剪了与 worktree 无关的 git fetch origin 范围子节（对应 commit c50af2b）。建议合并前采纳 P2 两条 suggestion（占位符统一 + squash-merge 注释），其余 P3 可作为后续增量。

Review by AI Assistant

[LetMeFly666]

PR Review — #1548 docs: add git worktree (create & delete) to AI-maintained tech notes

PR 概要

本次 PR 在 Solutions/Other-AI-LLM_Maintained_TechNotes.md 的技术随笔中新增 ## Git 章节，系统整理 git worktree 的 创建 / 删除 / 术语 / 常见坑。内容源自 PR #1536 的评论区讨论，+68 / -0，单文件改动，不涉及代码逻辑，属于纯文档追加。

代码正确性分析

文件 变更类型 正确性 说明
Solutions/Other-AI-LLM_Maintained_TechNotes.md 追加章节 ✅ 技术描述总体准确 创建/删除命令、术语、边界情形均对；少量表述可进一步严谨

潜在问题与建议

P2 — 方式 B 示例里硬编码了 1536，与方式 A / C 的 feat/xxx/yyy 占位符不一致 方式 A 使用 feat/xxx/yyy 作为"任意分支名"占位符，读者一看便知是需要替换的占位。但方式 B 突然出现 pull/1536/head:pr-1536，1536 是 PR #1536（本 PR 知识点来源的那条 PR 的编号），会让读者误以为这个数字有特殊含义，或以为只能用于某个具体 PR。建议统一用 <N> 占位符，与上文的 <主仓库目录>、下文的 :local-name 风格一致。

P2 — git branch -d 在 squash-merge 场景会失败，应补充说明 第 270 行注释写"merge 过用 -d，未 merge 用 -D"。但 GitHub 上最常见的合并方式之一是 Squash & Merge——合并后 master 上的提交 SHA 与本地分支 tip 完全不同，git branch -d 检查不到"merged into upstream"，会拒绝删除并要求 -D。这是 worktree 清理流程中非常高频的真实坑（尤其是本仓库 PR 大量走 squash），文档里若不提醒，读者实操时第一次就会踩到。建议把注释里的条件加一条。

P3 — "目录已被手动 rm -rf" 行的处理建议可更精确 第 283 行说目录被手动 rm -rf 后 "改用 git worktree prune 清残留元信息"。实测中，新版 Git（≥ 2.17）里 git worktree remove <path> 对已被手动删除的目录会直接失败并提示使用 prune，这一点描述无误。但也可补一句"或直接 git worktree remove --force <path>"——某些 Git 版本下加 --force 也能清掉元信息，作为备选。此点属锦上添花，可不改。

P3 — "是只读 ref" 的表述稍口语 第 254 行表格里 "是只读 ref，需要 :local-name 才便于 push" 的"只读"严格说不准确：pull/<N>/head 是 server-side 特殊 ref，客户端 fetch 后拿到的是普通对象，只是 push 回 refs/pull/<N>/head 不被 GitHub 接受（必须 push 到源分支）。表述上可改成 "指向 PR head 的远端特殊 ref，不能直接 push 回去更新 PR"。此点非阻塞。

P3 — git fetch origin feat/xxx/yyy:feat/xxx/yyy 在本地分支已存在且分叉时会失败 方式 A 的一句话注释"只拉这一条 ref，最省带宽"准确，但没提示：若本地已有同名分支且与远端分叉，这条 fetch 会以 non-fast-forward 被拒绝，此时需 + 前缀（+feat/xxx/yyy:feat/xxx/yyy）强制更新或改用其他命令。对新手常见坑，可在"常见坑"段落加一条。非阻塞。

总结表格

维度 评级 说明
技术准确性 🟢 Good 核心命令、语义、清理流程均对
完整性 🟡 Fair 缺少 squash-merge 对 -d 的影响提醒；fetch 覆盖分叉分支未提
可读性 🟢 Good 结构清晰：场景 → 创建 → 术语 → 删除 → 坑
一致性 🟡 Fair 方式 B 示例用 1536 硬编码，与方式 A / C 的 xxx/yyy 占位不一致
风险 🟢 None 纯文档追加，不影响任何代码路径

最终合并建议

可合并 — 技术内容无误，属有价值的知识沉淀，且已在本轮互动中修剪了与 worktree 无关的 git fetch origin 范围子节（对应 commit c50af2b）。建议合并前采纳 P2 两条 suggestion（占位符统一 + squash-merge 注释），其余 P3 可作为后续增量。

Review by AI Assistant

还串台了哈哈，reviewer变成user了