用途
Git 工作流与版本管理是一套用于规范代码变更流程的实践指南。它把 Git 定位为安全网：提交是存档点，分支是沙盒，历史是文档。在 AI 智能体高速生成代码的场景下，纪律化的版本控制是让变更保持可管理、可审查、可回滚的机制。该技能适用于任何代码变更——资料明确说明“始终适用，每一次代码变更都流经 git”。
核心原则
主干开发（推荐）：保持 main 始终可部署，在 1-3 天内合并回主干的短生命周期特性分支中工作。长期存在的开发分支是隐性成本——它们会分叉、产生合并冲突并延迟集成。资料称 DORA 研究一致表明主干开发与高绩效工程团队相关。发布分支是可接受的；特性开关优于长期分支。
尽早提交、频繁提交：每个成功的增量单独提交，不要累积大量未提交变更。工作模式为“实现切片 → 测试 → 验证 → 提交 → 下一个切片”，而非“实现全部 → 期望能跑通 → 巨型提交”。
原子提交：每个提交只做一件逻辑上的事。资料给出正反示例：好的提交日志是“添加任务创建端点及校验”“添加任务创建表单组件”“连接表单到 API 并添加加载状态”“添加任务创建测试（单元 + 集成）”；坏的提交日志则是把任务功能、修复侧边栏、更新依赖、重构工具混在一起。
描述性提交信息：提交信息解释“为什么”而非仅“是什么”。格式为 <type>: <short description> 加可选正文。类型包括 feat（新功能）、fix（缺陷修复）、refactor（既不修缺陷也不加功能的代码变更）、test（新增或更新测试）、docs（仅文档）、chore（工具、依赖、配置）。
关注点分离：不要把格式化变更与行为变更混在一起，不要把重构与功能混在一起。重构变更和功能变更应分别提交，理想情况下分别提 PR。小型清理（如重命名变量）可由审查者酌情包含在功能提交中。
控制变更规模：目标每个提交/PR 约 100 行；约 300 行对单一逻辑变更可接受；超过约 1000 行应拆分。
分支策略
特性分支从 main（或团队默认分支）拉出，每个分支一个功能，保持短生命周期（1-3 天内合并），合并后删除分支。命名约定：feature/<short-description>、fix/<short-description>、chore/<short-description>、refactor/<short-description>。
使用 worktree 并行工作：为并行 AI 智能体工作，可用 git worktree 同时运行多个分支。资料给出命令：git worktree add ../project-feature-a feature/task-creation、git worktree add ../project-feature-b feature/user-settings，完成后用 git worktree remove ../project-feature-a 清理。好处包括多个智能体可同时处理不同功能、无需切换分支、实验失败可删除 worktree、变更在显式合并前保持隔离。
存档点模式
智能体开始工作 → 做出变更 → 测试通过则提交并继续，测试失败则回退到上次提交并调查 → 再做变更，重复此过程 → 功能完成时所有提交形成干净历史。该模式意味着永远不会丢失超过一个增量的工作；若智能体跑偏，git reset --hard HEAD 可回到上次成功状态。
变更摘要
任何修改后提供结构化摘要，包含三部分：CHANGES MADE（改了什么）、THINGS I DIDN'T TOUCH（有意未触碰的内容）、POTENTIAL CONCERNS（潜在顾虑）。资料强调“未触碰”部分尤其重要，表明执行了范围纪律，没有进行未经请求的大改造。
提交前卫生
每次提交前：检查暂存内容（git diff --staged）、确保无密钥（用 grep 搜索 password/secret/api_key/token）、运行测试（npm test）、运行 lint（npm run lint）、运行类型检查（npx tsc --noEmit）。可用 git hooks 自动化，资料给出 lint-staged + husky 的 package.json 配置示例。
生成文件处理：仅当项目期望时才提交生成文件（如 package-lock.json、Prisma 迁移）；不要提交构建输出（dist/、.next/）、环境文件（.env）或 IDE 配置。.gitignore 应覆盖 node_modules/、dist/、.env、.env.local、*.pem。
用 Git 调试
资料列出：git bisect 定位引入缺陷的提交；git log --oneline -20 和 git diff HEAD~5..HEAD -- src/ 查看近期变更；git blame 查找某行最后修改者；git log --grep="validation" --oneline 搜索提交信息。
发布与版本管理
当有其他方依赖你的代码时，“main 上的最新版”不再是充分答案。版本号与变更日志是回答“我在运行什么、升级是否安全”的契约。
语义化版本：MAJOR 为破坏性变更（使用者必须改代码才能升级）、MINOR 为向后兼容的新功能、PATCH 为向后兼容的缺陷修复。数字是承诺，代码要与之匹配。不确定是否为破坏性变更时，假定是。
打标签：发布是历史中不可变的点，不是移动的分支。用 git tag -a v1.4.0 -m "Release 1.4.0" 和 git push origin v1.4.0。版本应从标签派生，而非在分散文件中手工编辑，以免制品、标签和变更日志不一致。
面向人类的变更日志：变更日志不是 git log，而是按 Added / Changed / Fixed / Deprecated / Removed / Security 分组、最新在上、每条围绕用户影响而非内部机制的精选内容。资料给出示例条目，并建议在做出变更的同一变更中撰写条目，破坏性变更需附迁移说明和弃用窗口。
常见借口与红旗信号
资料列出常见借口及其现实，例如“功能完成再提交”（巨型提交无法审查、调试或回滚）、“提交信息不重要”（信息是文档）、“以后再拆分”（大变更更难审查、部署风险更高、更难回滚）、“变更日志就是提交日志”（提交给你看，变更日志给使用者看）。红旗信号包括：大量未提交变更累积、提交信息如“fix”“update”“misc”、格式化与行为变更混杂、项目无 .gitignore、提交 node_modules/ 或 .env、长期分支严重偏离 main、向共享分支强推、破坏性变更以 minor 或 patch 版本发布、发布无标签或版本号与标签不同步、面向用户的发布无变更日志条目。
验证清单
每次提交：提交只做一件逻辑事；信息解释为什么并遵循类型约定；提交前测试通过；diff 中无密钥；无仅格式化变更与行为变更混杂；.gitignore 覆盖标准排除项。每次发布（任何有使用者的东西）：版本号提升与变更匹配（破坏性→major、新增→minor、修复→patch）；发布已打标签且版本从标签派生；变更日志有按影响分组的、人类可读的精选条目。
限制
资料未提供该技能的具体安装方式、收费模式、支持平台或与其他工具的集成细节，这些信息暂未提供。