用途与核心思想
该技能用于指导专业化的 Git 版本控制实践，强调三个核心理念：
- 基于主干的开发（Trunk-Based Development）：main 分支始终保持可部署状态；特性分支应短生命周期（数天而非数周）；频繁集成到 main；改动小而增量；保持持续集成思维。
- Conventional Commits：使用结构化、语义化的提交信息，便于自动化工具生成变更日志与版本号。
- GitHub 集成：通过 Pull Request 进行代码评审，使用分支保护、GitHub Actions 实现 CI/CD，并撰写清晰的 PR 描述。
基于主干的开发工作流
- main 分支：始终可部署、受保护（要求 PR、评审、CI 通过），是所有分支的源头和归并目标；避免 develop、staging 之类的长期分支。
- 特性分支流程：从 main 拉出分支，形成小而聚焦的改动，频繁提交，保持 1–3 天的分支寿命，并通过 rebase 与 main 保持同步；推送后创建 PR，合入后立即删除分支。
- 分支命名规范：格式为
<type>/<short-description>，类型与 Conventional Commit 类型一致，例如feat/add-oauth-login、fix/authentication-timeout、refactor/database-queries、docs/api-endpoints、test/user-service、chore/update-dependencies；描述用短小写、连字符分隔。
Conventional Commits
格式为 <type>(<scope>): <subject>，后接空行分隔的可选 body 与 footer；type 与 subject 必填，scope、body、footer 可选。
常用类型包括：feat（新功能）、fix（缺陷修复）、docs（文档）、style（代码风格，不改逻辑）、refactor（重构，不改行为）、perf（性能优化）、test（测试）、build（构建系统或依赖）、ci（CI/CD 配置）、chore（维护任务）、revert（回滚提交）。
scope 可选但推荐，用于标明代码库中受影响的模块（如 api、ui、database、auth）。subject 规则：使用祈使语气（add 而非 added）、首字母不大写、结尾不加句号、50 字符以内，并能补全句子"If applied, this commit will..."。
body 用于说明做了什么与为什么，行宽 72 字符，用空行与 subject 分隔，可用项目符号列出多点。footer 用于破坏性变更（BREAKING CHANGE: 或类型后加 !）和 issue 引用（Fixes #123、Closes #456）。文档中给出了简单功能、带详情的缺陷修复、破坏性变更、多重改动等示例。
常用 Git 命令
资料整理了日常命令（git status、git diff、git add、git commit、git pull/push/fetch、分支创建切换删除）、工作流命令（用 rebase 更新特性分支、--force-with-lease 推送、--amend 修改提交、reset 取消暂存、restore/clean 丢弃改动、stash 系列、git log 多种查看方式、分支比较），并指向参考资料中的完整命令清单。
GitHub Pull Request 流程
- 创建 PR：推送分支后用 Conventional Commit 格式写标题；描述模板包含 Summary、Changes、Testing、Screenshots（UI 变更时）、Checklist（测试、文档、破坏性变更、提交规范）。随后请求评审并关联 issue。
- 评审 PR：检查代码质量与风格、测试是否充分、本地验证功能、提问与建议，最终批准或请求修改；资料附有评审清单（符合项目约定、测试充分、无多余改动、文档更新、提交规范、无安全漏洞、考虑性能影响）。
- 处理评审反馈：在分支上继续提交、回复评论、标记会话已解决、请求再次评审。
- 合并策略：Squash and merge（多数功能推荐，历史干净）、Merge commit（保留全部提交，适合复杂协作分支）、Rebase and merge（线性历史，要求分支历史整洁）；合并后删除远程与本地分支并更新 main。
分支保护与冲突处理
main 分支保护必选项：合并前要求 PR、至少 1 个审批、状态检查通过、分支保持最新。推荐项：要求解决对话、要求线性历史、禁止绕过设置、自动删除头分支。团队可选：Code Owners 评审、限制推送权限、要求签名提交。
冲突处理：先用 git status 查看冲突文件，手动编辑冲突标记（<<<<<<<、=======、>>>>>>>），git add 标记已解决，再用 git commit（merge）或 git rebase --continue（rebase）继续；必要时用 --abort 中止。预防方式包括频繁从 main 拉取/变基、保持分支短命、与团队协调重叠工作、保持小改动。
常见工作流与最佳实践
资料列出新功能开发、快速缺陷修复、从 main 更新分支（rebase 优先或 merge）、拆分过大分支等流程。最佳实践分为提交、分支、协作、仓库整洁四类，例如：频繁提交、一次提交一个逻辑变更、提交前测试与 git diff 自查；不向 main 提交坏代码、不写含糊信息、不提交敏感数据、不直接推送 main；分支短命、合并后删除；协作中先拉取、及时评审、使用 PR 模板、关联 issue；仓库使用 .gitignore、打标签发布、不提交构建产物/依赖/IDE 文件/大二进制文件等。
故障排查与进阶
针对"提交到错误分支""撤销上次提交""提交了敏感数据""分支与 main 分叉""修改提交信息""rebase 出错"等场景给出具体命令步骤；提交敏感数据后除清理历史外，还需轮换已泄露的密钥。进阶内容涵盖交互式 rebase（pick、reword、edit、squash、fixup、drop）与 cherry-pick 单个、多个及范围提交。
适用场景与限制
适合团队制定 Git 工作流规范、个人开发者养成规范提交与 PR 协作习惯、处理日常版本控制问题。资料未说明该技能的安装方式、运行平台、是否收费或效果承诺，这些信息暂未提供；内容以文字指导和命令示例为主，实际执行需结合自身仓库与团队约定。