引言
咱们先打个比方，就像几个人合写一本小说。如果大家都直接在同一个文档上改，很快就会乱套：有人删了重要情节，有人同时修改同一段落，最后谁也不知道哪个版本是对的。
Git 则是管理这些变化的利器，而'工作流程'就是大家约定好的规矩。没有规矩，再好的工具也会用乱。今天，我就带你理清各种 Git 工作流，找到适合你团队的那一套。
一、Git 核心概念
- 仓库：就是你的项目文件夹，Git 会记录里面所有文件的变化
- 提交：相当于给当前版本拍张'快照'，并写上说明
- 分支：从主线分出去的'平行世界'，可以在里面大胆实验而不影响主线
- 合并：把分支的改动整合回主线
简单来说，仓库就是图书馆，提交是各种书籍，分支是草稿本，合并是把定稿收进图书馆。
二、四种主流工作流
中心化工作流
- 核心模式：只有一个主分支，所有人直接在上面提交
- 适用场景：2-3 人的小团队、个人项目
- 优点：简单，不用考虑分支管理
- 缺点：容易冲突，不适合多人协作
通俗比喻：大家一起在一个本子上写作业
功能分支工作流
- 核心模式：每做一个新功能，就从主分支拉一个新分支，做完后通过'拉取请求'合并
- 适用场景：大多数中小型团队
- 优点：代码有审查，减少错误
- 缺点：分支可能很多
关键动作示例：
# 创建功能分支
git checkout -b feature-login-page
# 开发并提交代码
git add .
git commit -m "feat: login page implementation"
# 推送到远程仓库
git push origin feature-login-page
# 在 GitHub/GitLab 创建 Pull Request，等待同事审查合并
通俗比喻：每人发个草稿本，写好了互相检查再抄到正式本上
GitFlow 工作流
- 分支结构：
- master：只放稳定可发布的代码
- develop：日常开发的主分支
- feature/*：功能分支
- release/*：发布前的测试分支
- hotfix/*：紧急修复分支
- 适用场景：有固定发布周期的大型项目、企业级应用
- 优点：流程清晰，适合复杂项目管理
- 缺点：流程复杂，学习成本高
通俗比喻：像汽车工厂流水线，每个环节严格分工
Forking 工作流
- 核心模式：每个人复制整个项目到自己的账户，修改后申请合并
- 适用场景：开源项目、不直接信任的贡献者
- 优点：维护者完全控制，贡献者无需权限
- 缺点：同步更新麻烦
通俗比喻：大家都抄一本参考书，改好了给老师看，老师觉得好就放进标准答案
场景选择推荐
- 3 人以下小项目 → 中心化或功能分支
- 5-20 人创业团队 → 功能分支工作流
- 50 人以上大公司 → GitFlow
- 开源项目 → Forking 工作流
- 经常紧急上线 → 功能分支 + 简单 GitFlow
三、Git 实用工具和小技巧
Git 钩子
- 提交前自动检查代码格式
- 推送前自动运行测试
- 安装 Commitizen，让提交信息更规范
急救命令
# 撤销上一次提交但保留修改
reset --soft HEAD~1
# 查看谁改了哪行代码（甩锅必备）
git blame <文件名>
# 暂时保存手头工作，去处理紧急 bug
git stash
# 处理完回来继续
git stash pop
四、一些小建议
- 从简单开始：先掌握功能分支工作流，够用 80% 的场景
- 工具辅助：用 VS Code 的 Git 图形界面，比命令行直观
- 团队一致：团队统一用同一套流程，比用'最好'的流程更重要
- 文档化：把你们的流程写成文档，新同事一看就懂
