Git 工作流与版本管理

在 AI 辅助编程的场景里，代码产出速度远高于人工评审速度。结果往往是：一个文件被连续改了几十次却没有提交，一次任务堆了十几项改动；功能分支拖到两周后才合并，main 已经不是可发布状态；等到要回退时，只能靠 git reset --hard 或者临时打补丁，历史里找不到可解释的依据。

核心原则：主干开发优先

该技能推荐 Trunk-Based Development 作为默认模型：main 始终保持可部署，功能改动放进短生命周期分支，1 到 3 天内合并回主干。理由很直接：开发分支存在的时间越长，合并风险越高，冲突越难解，集成反馈越滞后。DORA 的研究也反复指出，主干开发与高绩效工程团队显著相关。

当然，分支模型不是铁律。如果你的团队用 gitflow 或长期分支，完全可以保留现有流程，但要吸收同一套纪律：

• 原子提交：一次提交只做一件逻辑上完整的事
• 小步变更：避免把重构、修 bug、加功能混在同一个提交里
• 描述性信息：提交说明解释动机，而不只是复述改动

另外，特性开关优于长期分支。功能还没写完时，用开关把它隐藏起来并部署到主干，而不是把整个功能压在分支上数周。发布分支则可以用于稳定版本，同时主干继续向前推进。

早提交与原子提交

每当某个改动成功跑通，就立刻提交，不要让大量未提交改动堆积。提交在这里扮演的是存档点：如果下一步把东西搞坏了，你可以瞬间回退到上一个已知良好状态。

原子提交要求把工作拆成边界清晰的单元：一次提交只做加校验、一次提交只做重命名、一次提交只做修 bug。这样 git blame 才有可读性，git bisect 才能快速定位问题提交。

描述性提交信息

好的提交信息应该回答“为什么这样做”，而不是只描述“做了什么”：

feat: add email validation to registration endpoint

Prevents invalid email addresses reaching the database,
which caused spam tickets and downstream sync failures.

这样别人回看历史时，能理解设计意图，而不是猜测某行代码为什么存在。

安全网思路

Git 是整套工作流的安全网。把提交当作存档点，把分支当作沙箱，把历史当作文档。当 AI agent 高速生成代码时，有纪律的版本控制才是让变更可控、可审、可回退的关键机制。

适用边界与注意点

这个技能默认你的代码已经托管在 Git 仓库里，并且团队接受以主干为集成中心的思路。如果你的项目使用其他版本控制系统，需要先做迁移评估。

分支模型可以按团队实际调整。主干开发的推荐适用于大多数持续交付场景，但合规要求严格的团队可能需要长期分支配合审批流程——此时更应该坚持原子提交和描述性信息，因为分支越长，这些纪律的价值越大。

如果历史已经被大量无意义提交污染，不要试图一次性改写历史。先从新分支开始建立规范，旧历史按团队策略逐步清理。