引言
版本控制是团队协作的基础。Git 作为超级版本管理器，其工作流程如同约定好的写作规矩，确保多人协作有序进行。
一、Git 核心概念
- 仓库：项目文件夹，Git 记录文件变化
- 提交：给当前版本拍'快照'并写说明
- 分支：从主线分出的'平行世界'，可大胆实验
- 合并：将分支改动整合回主线
简而言之，仓库即图书馆，提交是书籍，分支是草稿本，合并是将定稿收进图书馆。
二、四种主流工作流
中心化工作流
- 怎么玩：只有一个主分支，所有人直接提交
- 适合谁：2-3 人小团队、个人项目
- 优点：简单，无需分支管理
- 缺点：易冲突，不适合多人协作
一句话总结：大家一起在一个本子上写作业
功能分支工作流
- 怎么玩：每做新功能拉新分支，完成后通过'拉取请求'合并
- 适合谁：大多数中小型团队
- 优点：代码审查，减少错误
- 缺点：分支可能很多
关键动作：
git checkout -b 新功能 - 登录页面 // 创建功能分支
# 开发、提交...
git push origin 新功能 - 登录页面 // 推到远程
# 在 GitHub/GitLab 创建 Pull Request
# 同事审查后合并
一句话总结：每人发个草稿本，写好了互相检查再抄到正式本上
GitFlow 工作流
- 分支结构：
- master：只放稳定可发布代码
- develop：日常开发主分支
- feature/*：功能分支
- release/*：发布前测试分支
- hotfix/*：紧急修复分支
- 适合谁：有固定发布周期的大型项目、企业级应用
- 优点：流程清晰，适合复杂项目管理
- 缺点：流程复杂，学习成本高
一句话总结：像汽车工厂流水线，每个环节严格分工
Forking 工作流
- 怎么玩：每个人复制整个项目到自己的账户，修改后申请合并
- 适合谁：开源项目、不直接信任的贡献者
- 优点：维护者完全控制，贡献者无需权限
- 缺点：同步更新麻烦
一句话总结：大家都抄一本参考书，改好了给老师看，老师觉得好就放进标准答案
场景选择推荐
- 3 人以下小项目 → 中心化或功能分支
- 5-20 人创业团队 → 功能分支工作流
- 50 人以上大公司 → GitFlow
- 开源项目 → Forking 工作流
