用途
该技能用于规范 Git 工作流与版本管理实践。资料指出，每个代码变更都应经过 git，因此它适用于进行任何代码变更时，包括提交、分支、解决冲突、把混乱 working tree 里未提交的工作拆成干净的 atomic commits、创建或审查 pull request（PR）、推送到远程，或需要组织多个并行工作流时；也用于裁剪 release、选择语义化版本递增、打标签或编写 changelog。
核心原则
主干开发（推荐）：保持 main 始终可部署，在短生命周期 feature branches 中工作，并在 1-3 天内合回。资料称长期存在的开发分支是隐藏成本，会分叉、制造 merge conflicts 并延迟集成，并提到 DORA 研究持续表明 trunk-based development 与高绩效工程团队相关。使用 gitflow 或长期分支的团队可以把这些原则适配到自己的分支模型中，commit 纪律比具体分支策略更重要。Release branches 可以接受，用于在 main 继续前进时稳定某个 release；feature flags 优于长期分支。
尽早提交，经常提交：每个成功的增量都应有自己的 commit，不要累积大量未提交变更。工作模式为“实现切片 → 测试 → 验证 → 提交 → 下一个切片”，而非“实现全部 → 期望能跑 → 巨型提交”。
原子提交：每个 commit 只做一件逻辑上的事情。资料给出正反示例，好的提交如“Add task creation endpoint with validation”“Add task creation form component”等各自独立，坏的提交则把功能、修复、依赖更新、重构混在一起。
描述性消息：commit messages 解释 why 而不只是 what。格式为 <type>: <short description> 加可选正文。类型包括 feat（新功能）、fix（Bug fix）、refactor（既不修 bug 也不加功能的代码变更）、test（添加或更新测试）、docs（仅文档）、chore（工具、依赖、配置）。
保持关注点分离：不要把格式变更和行为变更混在一起，不要把重构和功能混在一起，每种类型变更应是单独 commit，理想情况下也是单独 PR。小型清理可由审查者判断是否包含在功能 commit 中。
控制变更大小：目标是每个 commit/PR 约 100 行，约 300 行对单个逻辑变更可接受，超过约 1000 行的变更应拆分。
分支策略
Feature Branches：从 main（或团队默认分支）创建分支，保持短生命周期（1-3 天内合并），合并后删除分支，对未完成功能优先使用 feature flags。分支命名约定包括 feature/<short-description>、fix/<short-description>、chore/<short-description>、refactor/<short-description>。
使用 Worktrees：对于并行 AI agent 工作，使用 git worktrees 同时运行多个分支，例如 git worktree add ../project-feature-a feature/task-creation。收益包括多个 agents 可同时处理不同功能、不需要切换分支、实验失败可删除 worktree、变更在明确合并前彼此隔离。
保存点模式与变更总结
保存点模式：Agent 开始工作 → 做出变更 → 测试通过则提交并继续，测试失败则回退到上一个 commit 并调查 → 功能完成，所有 commits 形成干净历史。这意味着最多只丢失一个增量的工作，git reset --hard HEAD 可回到最后一个成功状态。
任何修改之后都提供结构化总结，包含 CHANGES MADE、THINGS I DIDN'T TOUCH (intentionally)、POTENTIAL CONCERNS 三部分，以捕捉错误假设并给审查者清晰的变更地图。
Pre-Commit 卫生与生成文件
每次 commit 之前：检查 git diff --staged、确保无 secrets、运行测试、运行 linting、运行类型检查。可用 git hooks 自动化，例如 lint-staged + husky 配置。
处理生成文件：只有项目期望时才 commit 生成文件（如 package-lock.json、Prisma migrations）；不要 commit build output（dist/, .next/）、环境文件（.env）或 IDE config；准备 .gitignore 覆盖 node_modules/、dist/、.env、.env.local、*.pem。
用 Git 调试
资料给出 git bisect、git log --oneline -20、git diff HEAD~5..HEAD -- src/、git blame、git log --grep 等命令用于定位引入 bug 的提交、查看近期变更、查找特定行的最后修改者、按关键词搜索提交信息。
发布与版本管理
语义化版本：按 MAJOR.MINOR.PATCH 版本化。MAJOR 为 breaking change，使用者必须改代码才能升级；MINOR 为向后兼容的新功能；PATCH 为向后兼容的 bug fix。拿不准是否 breaking 时，就当它是。
打 tag：Release 是历史中不可变点，用 git tag -a v1.4.0 -m "Release 1.4.0" 和 git push origin v1.4.0 打标签，从 tag 派生版本号，避免构建产物、tag 和 changelog 互相矛盾。
维护 changelog：changelog 不是 git log，而是经过整理、面向使用者的答案，按 Added / Changed / Fixed / Deprecated / Removed / Security 分组，最新在顶部，条目围绕用户影响措辞。在做变更的同一个变更里写好对应条目。Breaking changes 要有迁移说明和弃用窗口。
常见合理化借口与危险信号
资料列出多条合理化借口及现实，例如“功能完成后再 commit”“消息不重要”“以后全部 squash”“分支增加开销”“以后再拆这个变更”“我不需要 .gitignore”“只是个小修复，patch 加一就行”“changelog 就是 commit log”“发布时再补 changelog”。危险信号包括累积大量未提交变更、提交信息像 fix/update/misc、格式与行为变更混在一起、没有 .gitignore、提交 node_modules/.env/build artifacts、长期分支与 main 显著分叉、force-pushing 到共享分支、breaking change 藏在 minor 或 patch 下发布、release 没有 tag 或版本号手动编辑到与 tag 不同步、面向用户的 release 没有 changelog 条目。
验证清单
对每个 commit：只做一件逻辑上的事；message 解释 why 并遵循类型约定；提交前测试通过；diff 中没有 secrets；没有把纯格式变更混入行为变更；.gitignore 覆盖标准排除项。对每个 release：版本递增与变更匹配；release 已打 tag 且版本号从 tag 派生；changelog 中有按影响分组的、经过整理的、人类可读的条目。