用途
本技能提供 Git 版本控制的工作流模式与最佳实践，用于指导团队协作开发中的分支策略、提交规范、代码评审、冲突处理与发布管理。适用于为新项目搭建 Git 工作流、决定分支策略、撰写提交信息与 PR 描述、解决合并冲突、管理发布与版本标签，以及帮助新成员熟悉 Git 实践等场景。
主要能力
分支策略
提供三种策略及其适用条件：
- GitHub Flow：适合持续部署与中小团队。main 始终可部署，从 main 创建功能分支，通过 PR 评审，CI 通过后合并到 main 并立即部署。
- 主干开发（Trunk-Based）：适合具备强 CI/CD 与功能开关的高速度团队。所有人提交到 main 或极短生命周期分支（最多 1-2 天），用功能开关隐藏未完成工作，每天多次部署。
- GitFlow：适合按发布周期驱动的企业项目。main 仅含生产就绪代码，develop 为集成分支，功能分支从 develop 创建并合回，发布分支合并到 main 与 develop，热修复分支从 main 创建并合并到两者。
选择建议：GitHub Flow 适合任意团队规模、持续发布、SaaS/Web 应用与初创；主干开发适合 5 人以上有经验团队、每天多次发布；GitFlow 适合 10 人以上、按计划发布、企业与受监管行业。
提交信息规范
采用 Conventional Commits 格式：<type>(<scope>): <subject>，可选 body 与 footer。类型包括 feat、fix、docs、style、refactor、test、chore、perf、ci、revert。提供好与坏的示例对比，以及 .gitmessage 模板，可通过 git config commit.template .gitmessage 启用。
合并与变基
- 合并（Merge）：创建合并提交，保留完整历史。适用于将功能分支合入 main、需要保留精确历史、多人协作的分支、已推送且他人可能基于其工作的分支。
- 变基（Rebase）：将功能提交重写到目标分支上，形成线性历史。适用于用最新 main 更新本地功能分支、追求线性整洁历史、仅本地未推送的分支、单人开发的分支。
明确列出不应变基的情况：已推送到共享仓库、他人已基于其工作、受保护分支（main、develop）、已合并的分支。变基会重写历史，破坏他人工作。
Pull Request 流程
提供 PR 标题格式、PR 描述模板（What、Why、How、Testing、Screenshots、Checklist）、代码评审清单（评审者与作者各自关注点）。
冲突解决
包含识别冲突、查看冲突标记、手动解决、使用 mergetool、接受某一方（--ours/--theirs）等命令，以及冲突预防策略：保持功能分支小而短、频繁变基、就共享文件与团队沟通、用功能开关替代长期分支、及时评审合并 PR。
分支管理
提供命名约定（feature/、fix/、hotfix/、release/、experiment/、poc/）与分支清理命令。
发布管理
语义化版本 MAJOR.MINOR.PATCH 规则、创建带注释标签、推送标签、列出与删除标签、从提交生成变更日志。
Git 配置与别名
提供用户身份、默认分支名、pull.rebase、push.default、diff.algorithm、color.ui 等配置，以及常用别名（co、br、ci、st、unstage、last、visual、amend、wip、undo、contributors）。
Gitignore 模式
涵盖依赖、构建产物、环境文件、IDE、操作系统文件、日志、测试覆盖率、缓存等常见忽略项。
常见工作流
开始新功能、更新 PR、同步 fork 与上游、撤销错误（reset、revert、amend、checkout 文件）。
Git Hooks
提供 pre-commit（运行 lint、测试、检查密钥）与 pre-push（运行完整测试、检查 console.log）示例脚本。
反模式
列出应避免的做法：直接提交到 main、提交密钥、巨型 PR、模糊提交信息、重写公共历史、长期功能分支、提交生成文件。
使用方式
本技能以文档形式提供命令与模板，用户可依据自身项目情况选用相应策略与命令。所有命令均为标准 Git 命令，可直接在终端执行。
适用场景
- 新项目搭建 Git 工作流
- 团队决定分支策略
- 撰写提交信息与 PR 描述
- 解决合并冲突
- 管理发布与版本标签
- 新成员 Git 实践入门
限制
本技能为工作流指导文档，不包含自动化工具或脚本执行能力。具体策略选择需结合团队规模、发布节奏与 CI/CD 成熟度自行判断。资料未提供收费、价格、平台支持范围等信息。