技能介绍

先解决的问题

Git 的日常用法很容易碰到天花板：想在两个分支上并行改东西，只能 stash 来回切，WIP 提交到处都是；线上出了 bug，只能靠肉眼在历史里二分定位引入点；待合并的分支上是一长串 fix typo、wip 这类无意义提交；团队里 git add . 不看 diff、对共享分支裸 --force、忘记 .gitignore 导致构建产物和密钥入库，这类事故反复发生。这个技能针对的就是这些反复出现的具体场景。

核心能力与关键步骤

Worktrees：每个 worktree 有独立的工作目录，但共享同一个 .git 仓库。feature/a 和 feature/b 可以同时处于已检出状态，不再需要 stash 或提交 WIP 来切换分支。
Bisect：在提交历史里做二分查找，定位引入 bug 的那一笔。最快的路径是配合 git bisect run 把测试命令自动化，让机器替你完成二分。
Interactive Rebase：合并进主干之前用交互式 rebase 整理提交——合并碎提交、重写无意义的 message，让历史保持可读。
Git Hooks：pre-commit 对暂存文件跑 lint，commit-msg 校验提交信息格式，把检查左移到提交时刻。
Recovery Techniques：任何破坏性操作之前先查 reflog，它能告诉你 HEAD 曾经到过哪里。
别名、反模式与 Checklist：技能还整理了常用 aliases、一份明确的反模式清单（对共享分支裸 --force、推送后仍 rebase、不用 Git LFS 就提交大二进制文件等），以及可逐项勾选的实践 checklist。

适用边界

这些技巧不是魔法：worktree 解决的是并行工作流问题，不会替你管理分支生命周期；bisect run 需要一条能可靠判定成败的测试命令，项目没有可自动化的测试时只能退化为手动二分；交互式 rebase 会重写提交哈希，凡是已推送且被他人共享的提交，rebase 前必须先确认团队没有基于它继续工作；hooks 默认不随仓库分发，需要团队自行提交到 .git/hooks 或采用共享的 hook 管理方式。checklist 里的反模式本质上都是协作约定，工具能提醒，不能强制。