技能介绍

分支混乱是怎么开始的

在多人协作的仓库里，分支策略往往是最先失控的地方。有人直接在 main 上提交，有人把多个功能塞进同一个分支，PR 合并时才发现冲突早已堆积如山。提交历史里充斥着 fix bug、update 这类毫无信息量的消息，git blame 几乎无法追溯责任人。等到 CI 流水线红了，才发现有人在合并前根本没跑过测试。

技能做了什么

Git Workflow Skill 本质上是一本可被代理随时调用的便携式工作流手册，把工程团队约定固化成可执行的指导：

分支策略：明确主干分支与特性分支的边界，约定从哪个分支切出、往哪里合入。
提交规范：约束 commit message 的格式与语义，让历史记录可读、可查。
拉取请求：规定 PR 的描述结构、评审要求与合并前置条件。
合并选择：区分 merge 与 squash 的适用场景，避免仓库历史被噪声淹没。
CI 敏感协作：提醒代理在触发合并或变更分支时留意流水线状态，不要跳过 CI 直接合入。

代理拿到这份手册后，能在创建分支、提交代码、发起 PR 的各个环节自动遵循上述约定，而不是等到 review 时才被发现违规。

适用边界

它不负责替团队做出具体的技术决策——用 GitFlow 还是 Trunk-Based，靠 squash 还是 merge commit，仍需团队根据自身发布节奏定夺。手册只提供一致的执行框架。此外，若仓库未启用 GitHub Actions 或 GitLab CI，CI 敏感部分的提示会退化为纯文档建议，无法真正拦截违规合并。