技能介绍

要解决什么问题

AI agent 以分钟级速度生成代码时，最常见的失控不是「写不出来」，而是「改得太多太快，没人记得住改了什么」。未提交的改动堆积、提交信息写成 update、行为变更和格式调整混在一个 commit 里、.env 被误提交——这些不是工具问题，而是版本控制纪律问题。当其他团队或包消费者开始依赖你的代码时，「main 上最新的」就不再是可回答的问题：我跑的是哪个版本？升级安全吗？

技能如何工作

主干优先。 推荐 Trunk-Based Development：main 始终可部署，功能在短生命周期分支上开发（1–3 天内合并），合并后删除分支。长期分支不是「功能开发」而是「隐藏成本」——分叉、冲突、延迟集成。不完整功能优先用 feature flag 而非长分支。

提交即存档点。 每个逻辑完整的增量独立提交；提交信息解释 why 而非只写 what，遵循 conventional types（feat / fix / refactor / test / docs / chore）。格式调整与行为变更分开提交，理想情况下分两个 PR。单次提交目标约 100 行，超过 ~1000 行必须拆分。

用 worktree 隔离实验。 AI agent 并行工作时，用 git worktree 让多个分支同时跑在各自目录里；某个实验失败，删掉 worktree 即可，什么都不会丢。配合 Save Point Pattern，git reset --hard HEAD 一次只损失一个增量。

发布不是随手 bump。 对外部消费者遵循 Semantic Versioning：breaking → major，additive → minor，fix → patch。版本号从 tag 派生，而非手工改散在各处的文件；release 是 tag 标记的不可变历史节点。changelog 写给人看——按 Added / Changed / Fixed / Deprecated / Removed / Security 分组，每条说明对用户的影响，且与改动同时编写，而不是发布前从 commit log 里考古。

适用边界

这套纪律适合任何提交频率上升的团队，但不必教条照搬：已用 gitflow 或长期分支的团队可以保留自己的分支模型，优先落实原子提交、小变更、描述性信息。Release branch 用于稳定发布期间 main 继续前进的场景是可接受的。记住版本号是承诺：一个「patch」若改变了消费者依赖的行为，就是穿着伪装的 major。