技能介绍

解决 Agent 时代的代码失控问题

当 Agent 高速产出代码时，改动往往迅速膨胀。缺乏纪律的版本控制会导致提交变成巨大的“黑盒”，分支生命周期过长引发合并冲突，版本号与变更日志形同虚设，最终让代码库变得不可管理、难以评审且无法安全回退。这个技能将 Git 重新定位为安全网：提交是存档点，分支是沙盒，历史是文档。

核心工作流与关键步骤

该技能不依赖特定的分支模型，而是强调提交纪律高于分支策略。其核心工作流包括：

原子提交与描述性消息：每次提交只做一件逻辑事（如“加校验中间件”或“加测试”）。提交信息需解释 为什么 而不仅是 做了什么，采用 type: scope: description 格式（如 feat: 注册端点加邮箱校验）。
关注点分离与规模控制：格式化与行为改动、重构与新功能必须分开提交。每个提交或 PR 的目标规模约为 100 行，超过 1000 行的改动必须拆分。
主干开发与存档点模式：保持 main 始终可部署，使用 1-3 天内合并的短生命周期特性分支。利用 git worktree 支持并行 Agent 工作。每次增量通过测试后立即提交，失败则通过 git reset --hard HEAD 瞬间回退。
提交前卫生与发布规范：提交前执行 git diff --staged 审查，扫描密钥，并运行测试与 lint。对外发布时，严格执行语义化版本（SemVer）控制，以 git tag 作为版本真相源，并生成围绕用户影响的变更日志（Changelog）。

适用边界与注意事项

此技能适用于所有涉及代码改动、分支管理、冲突解决及版本发布的场景。然而，它不适用于与版本控制无关的交互式实验。团队若使用 Gitflow 或长分支策略，可适配其原子提交与小改动原则，但需注意长生命周期分支的隐性成本。此外，生成的 VcsPlan 工件需交由增量实现、代码评审、发布部署等下游技能协同消费，实际的发布执行（如打标签推送）属于 shipping-and-launch 的职责范围。