Appearance
Git Workflow 解决的是 AI 改动太快、工作区失控的问题。它把 commit 当成保存点，把 branch 当成沙盒，让每次改动都小、清楚、可 review、可回退。
AI 改完代码怎么整理提交：Git Workflow 怎么用
下载 git-workflow-and-versioning 中文版 Skill ZIP
AI 一次能改很多文件。
这很爽，也很危险。
如果没有 Git 纪律，半小时后你可能看到一个巨大的 diff：功能、重构、格式化、测试、文案全混在一起。
git-workflow-and-versioning 这个技能的核心是：用版本管理给 AI 的速度加护栏。
commit 是保存点
每完成一个可验证小步骤，就应该有一个保存点。
节奏可以是：
text
实现一个小切片
↓
验证通过
↓
提交
↓
继续下一步这样后面出问题时，你最多回退一小段，不会丢掉整天工作。
原子提交比大提交更重要
一个提交只做一件事。
好的提交像这样：
feat: add api key input to settings pagetest: cover api key validation errorsfix: preserve pagination when filtering usersdocs: add skill library programming index
不好的提交像这样：
update filesfix stuffadd feature and refactor
AI 很容易把多个意图混在一个 diff 里。提交前要让它说明：哪些文件为什么变了，哪些改动属于同一件事。
不要把重构和功能混在一起
功能改动和重构改动要尽量分开。
因为 review 的关注点不同。
功能改动要看需求是否满足。重构改动要看行为是否保持。混在一起时，review 很难判断某个变化是业务需要，还是顺手整理。
如果 AI 先写功能，又发现需要重构，可以让它停下来：
md
这次先只完成需求。
如果确实需要重构，请单独列出原因和范围，不要混进当前改动。分支和 worktree 是隔离工具
多 Agent 或多任务并行时，分支和 worktree 很有用。
一个任务一个分支，互不干扰。试验失败，丢掉这个分支或 worktree，不影响主线。
但不要为了形式制造很多长期分支。分支放得越久，合并风险越大。
小步、短分支、快合并，比长期大分支更适合 AI 编程。
给 AI 的 Git Prompt
md
请先查看当前 git 状态。
整理本次改动时遵守：
1. 不要把无关文件放进同一个提交。
2. 功能、测试、文档、重构尽量分开。
3. 提交消息说明为什么改。
4. 不要使用破坏性 git 操作，除非我明确同意。Git 是安全网，不是清理战场的橡皮擦。
你可能还需要
同类技能：
AI 写得越快，越要让 Git 记录每一步为什么发生。