Git 工作流助手

这个技能能帮你做什么

代码写得好不好很重要，但代码管理得好不好同样重要。这个技能帮你建立一套清晰的 Git 工作流，让团队协作更顺畅，代码历史更清楚，出了问题也能快速定位。

简单说，它能帮你：

• 选择策略 —— 根据团队规模和项目特点，选择最适合的分支管理模式
• 规范提交 —— 写好提交信息，让代码历史一看就懂
• 处理冲突 —— 遇到合并冲突时不慌，按步骤解决
• 管理团队协作 —— 统一团队成员的工作方式，减少摩擦
• 发布管理 —— 规范版本发布和标签管理

什么时候用

项目启动时 —— 确定团队用什么分支策略、怎么提交代码

提交代码时 —— 不确定提交信息怎么写、要不要 rebase

遇到冲突时 —— 合并代码时出现冲突，不知道怎么处理

团队协作时 —— 多人同时开发，需要统一工作方式

发布版本时 —— 怎么打标签、怎么生成更新日志

新人入职时 —— 帮助新人快速了解团队的 Git 使用规范

主要覆盖哪些场景

1. 分支策略选择
   • GitHub Flow（简单推荐）：适合大多数团队，main 分支始终可部署，功能开发完直接合并
   • 主干开发：适合高速迭代的团队，大家都在 main 上开发，用功能开关控制未完成的功能
   • GitFlow：适合有固定发布周期的企业，分支多但管理规范
2. 提交规范
   • 统一的提交信息格式：类型(范围): 描述
   • 常用类型：feat（新功能）、fix（修复）、docs（文档）、refactor（重构）、test（测试）等
   • 写好提交信息，让代码历史清晰可读
3. 合并 vs 变基
   • 合并（Merge）：保留完整历史，适合多人协作的分支
   • 变基（Rebase）：整理成线性历史，适合个人本地分支
   • 什么时候用哪个？它会告诉你原则
4. 冲突处理
   • 识别哪些文件有冲突
   • 手动解决冲突的方法
   • 预防冲突的策略（小分支、频繁同步）
5. Pull Request 流程
   • PR 标题和描述怎么写
   • 审查清单（审查者和作者各自的检查项）
   • 合理的 PR 大小（建议小于 500 行）
6. 版本管理
   • 语义化版本号：主版本.次版本.补丁版本
   • 打标签和发布流程
   • 更新日志自动生成
7. 常用操作
   • 分支命名规范（feature/xxx、fix/xxx、hotfix/xxx）
   • 临时保存工作进度（git stash）
   • 撤销误操作（撤销提交、恢复文件等）

怎么用

新团队组建时 —— 告诉它"我们要开始新项目，推荐什么 Git 工作流"，它会根据你的情况建议

不确定怎么操作时 —— 问它"这个情况应该 merge 还是 rebase？"

遇到冲突时 —— 把冲突信息发给它，它会一步步教你解决

写提交信息时 —— 不确定怎么描述？它会给你模板和示例

审查代码时 —— 对照 PR 审查清单，确保不遗漏重要检查点

核心原则

使用 Git 时，记住这几条原则：

1. 小步快跑 —— 分支要小、提交要频繁、PR 要尽早提
2. 清晰历史 —— 提交信息写清楚做了什么、为什么做
3. 频繁同步 —— 经常从主分支同步，减少冲突概率
4. 主分支始终可用 —— main 分支上的代码随时都能部署
5. 代码审查不可少 —— 合并前必须经过审查，保证质量

适用场景

• 团队 Git 工作流建立和规范
• 个人开发者提升代码管理效率
• 多人协作时的冲突处理
• 项目版本发布管理
• 代码审查流程优化
• 新人 Git 培训

不适用场景

• 不需要版本控制的场景（如纯个人练习）
• 已经使用其他版本控制工具（如 SVN）
• 不涉及代码管理的场景
• 需要深入学习 Git 内部原理（这个是工作流指南，不是原理讲解）