用途
Git Workflow 是一套定义项目 Git 使用标准的技能，适用于用户提出创建 Git 提交、管理分支、遵循 Git 工作流、使用 Conventional Commits、处理合并等需求时。其目标是提升协作效率、实现可追溯性、支持自动化并减少冲突。
主要能力
提交信息规范
遵循 Conventional Commits 规范，格式为：
<type>(<scope>): <subject>
<body>
<footer>
类型包括：feat（新功能）、fix（缺陷修复）、docs（文档更新）、refactor（重构）、perf（性能优化）、test（测试相关）、chore（其他变更）。主题规则：以动词开头（add、fix、update、remove、optimize），不超过 50 个字符，结尾不加句号。
分支管理策略
分支类型与命名约定：
- master：主分支，可发布状态，永久存在
- develop：开发分支，最新集成代码，永久存在
- feature/feature-name：功能分支，完成后删除
- bugfix/issue-description：缺陷修复分支，修复后删除
- hotfix/issue-description：紧急修复分支，修复后删除
- release/version-number：发布分支，发布后删除
分支保护规则：master 分支不允许直接推送，必须通过 Pull Request 合并，必须通过 CI 检查，需要至少一次代码审查批准；develop 分支限制直接推送，建议通过 Pull Request 合并，必须通过 CI 检查。
工作流
提供三类标准流程：
- 日常开发工作流：同步最新代码 → 创建功能分支 → 开发并提交 → 推送到远程 → 创建 Pull Request 并请求代码审查 → 合并到 develop → 删除功能分支。
- 热修复工作流：从 master 创建修复分支 → 修复并提交 → 合并到 master 并打标签 → 同步到 develop。
- 发布工作流：创建发布分支 → 更新版本号和文档 → 提交版本更新 → 合并到 master 并打标签 → 同步到 develop。
合并策略
合并与变基的选择：合并保留完整历史，适用于公共分支和合并到主分支；变基产生线性历史，适用于私有分支和同步上游代码。建议：功能分支同步 develop 使用 rebase；功能分支合并到 develop 使用 merge --no-ff；develop 合并到 master 使用 merge --no-ff。项目约定合并功能分支时使用 --no-ff 以保留分支历史。
冲突解决
提供冲突识别方法、解决步骤（查看冲突文件 → 手动编辑 → 标记已解决 → 完成合并）、解决策略（保留当前分支版本、保留传入分支版本、中止合并）以及预防措施（定期同步代码、小步提交、模块化功能、团队沟通）。
.gitignore 规范
包含基本规则（忽略所有 .log 文件、忽略目录、忽略根目录下目录、忽略所有目录中的文件、不忽略特定文件）和常见 .gitignore 内容。
标签管理
使用语义化版本 MAJOR.MINOR.PATCH[-PRERELEASE]。版本变更规则：MAJOR 为不兼容的 API 变更，MINOR 为向后兼容的新功能，PATCH 为向后兼容的缺陷修复。提供创建附注标签、推送标签、查看标签、删除标签等操作。
团队协作规范
Pull Request 规范包含变更描述、变更类型、测试方法、关联 Issue、检查清单。代码审查关注代码质量、逻辑正确性、安全性、性能。
常见问题
涵盖修改最后一次提交、推送被拒绝、回滚到之前版本、暂存当前工作、查看文件修改历史等场景的处理方式。
使用方式
该技能以文档形式提供 Git 规范指导，包含参考文件和示例文件。参考文件包括 commit-conventions.md、branching-strategies.md、merge-strategies.md、conflict-resolution.md、advanced-usage.md、collaboration.md、gitignore-guide.md。示例文件包括 examples/commit-messages.txt 和 examples/workflow-commands.sh。
适用场景
适用于需要统一 Git 使用规范的团队项目，尤其是采用 Conventional Commits、多分支策略和代码审查流程的协作开发场景。
限制
该技能为规范文档，不包含自动化执行工具。具体安装命令、收费信息、平台支持等暂未提供。