Git 工作流与版本管理

要解决的问题

AI 代理生成代码的速度远超人工审查的节奏。一次对话可能产出数百行改动，涉及多个文件：模型不会替你区分哪些修改属于同一个意图，也不会自动判断这次改动是否安全。当变更量大且边界模糊时，团队面临三个具体问题：变更不可追踪（不知道哪个提交引入了 bug）、审查无从下手（一个提交里混了重构和功能开发）、回滚风险高（回退一个提交可能连带丢掉其他已完成的改动）。

Git 在这里是安全网，但前提是团队遵循一套纪律化的使用方式。这个技能把这种纪律固化下来。

技能如何工作

技能的核心是一套以主干开发（Trunk-Based Development）为默认的工作流原则，辅以提交纪律：

• main 始终可部署：所有工作通过短生命周期特性分支完成（1-3 天内合并回主干）。DORA 研究表明主干开发与高绩效工程团队持续相关。
• 分支即成本：开发分支存活的每一天都在积累合并风险。长命分支会漂移、制造冲突、推迟集成——技能明确将其定义为"隐藏成本"。
• 提交即存档点（save points）：每个成功的增量对应一个独立提交，出问题时可立即回退到上一个已知良好状态。
• 原子提交：每个提交只做一件事，自包含、可独立回退。提交消息描述意图，而不是复述代码改动。
• 特性开关优于长分支：未完成的工作量以 feature flag 形式部署在生产环境后面，而不是在分支上藏几周。
• 发布分支有明确用途：仅在需要稳定发布版本而 main 继续前进时使用。

适用场景覆盖所有代码变更——技能明确指出使用时机是"Always"，因为纪律本身（原子提交、小步变更、描述性消息）的价值大于具体分支策略的选择。

适用边界

这套技能不绑定工具链：不要求特定 CI 平台、代码托管服务或提交哈希格式，只描述原则，团队按现有基础设施落地。

它不否定其他分支模型：使用 Gitflow 或长命分支的团队可以只采用提交纪律部分（原子提交、小变更、描述性消息），分支策略按团队现状调整。技能明确指出，相比分支命名方式，提交纪律更重要。

它不替代发布工程：特性开关只是推迟完整发布的一种手段，不涵盖配置管理、灰度发布或回滚编排，这些需要团队自己的发布基础设施。