引言
团队协作写代码就像多人合写小说。如果大家都直接改同一个文档，冲突和混乱很快就会出现。Git 作为版本管理工具，核心价值在于解决协作问题，而工作流程则是团队约定的协作规范。没有规矩，再好的工具也难以发挥效率。
Git 核心概念
理解工作流前，先明确几个基础概念：
- 仓库 (Repository)：项目文件夹，Git 记录其中所有文件的变化历史。
- 提交 (Commit)：相当于给当前状态拍一张'快照'，并附带说明信息。
- 分支 (Branch)：从主线分出的'平行世界'，允许大胆实验而不影响主开发线。
- 合并 (Merge)：将分支的改动整合回主线，完成代码同步。
可以把它们想象成图书馆：仓库是图书馆本身，提交是入库的书籍，分支是草稿本，合并则是把定稿正式收进馆藏。
四种主流工作流
中心化工作流
- 模式：只有一个主分支，所有人直接向其提交。
- 适用场景：2-3 人的小团队或个人项目。
- 优缺点：简单直观，无需维护分支；但容易产生产生冲突，不适合大规模协作。
- 一句话总结：大家一起在一个本子上写作业。
功能分支工作流
- 模式：每个新功能独立拉取分支，开发完成后通过 Pull Request (PR) 合并。
- 适用场景：大多数中小型团队。
- 优缺点：代码可审查，降低错误率；但分支数量可能较多，需定期清理。
- 关键操作：
# 1. 创建并切换到新分支
git checkout -b feature-login-page
# 2. 开发并提交代码
# git add . && git commit -m "feat: login page"
# 3. 推送到远程仓库
git push origin feature-login-page
# 4. 在 GitHub/GitLab 创建 Pull Request 供同事审查
- 一句话总结：每人发个草稿本，写好了互相检查再抄到正式本上。
GitFlow 工作流
- 分支结构：
master：存放稳定可发布的代码。develop：日常开发的主分支。feature/*：功能分支。release/*：发布前的测试分支。hotfix/*：紧急修复分支。
- 适用场景：有固定发布周期的大型项目、企业级应用。
- 优缺点：流程清晰，适合复杂项目管理；但学习成本较高，流程略显繁琐。
- 一句话总结：像汽车工厂流水线，每个环节严格分工。
Forking 工作流
- 模式：每个人复制整个项目到自己的账户下，修改后申请合并。
- 适用场景：开源项目、不直接信任的贡献者环境。
- 优缺点：维护者完全控制权限，贡献者无需直接写入权限；但同步更新较为麻烦。
- 一句话总结：大家都抄一本参考书，改好了给老师看，老师觉得好就放进标准答案。
场景选择推荐
- 3 人以下小项目：中心化或功能分支。
- 5-20 人创业团队：功能分支工作流。
- 50 人以上大公司：GitFlow。
- 开源项目：Forking 工作流。
- 经常紧急上线：功能分支 + 简单 GitFlow。
Git 实用工具和小技巧
Git 钩子
利用钩子脚本可以自动化一些重复性工作：
- 提交前自动检查代码格式。
- 推送前自动运行单元测试。
- 安装 Commitizen 等工具，让提交信息更规范。
急救命令
遇到意外情况时，这些命令能帮你快速恢复：
# 不小心提交错了？撤销上一次提交但保留修改
git reset --soft HEAD~1
# 查看谁改了哪行代码（定位问题必备）
git blame 文件名
# 暂时保存手头工作，去处理紧急 bug
git stash
# 处理完回来继续
git stash pop
一些小建议
- 从简单开始：先掌握功能分支工作流，它能覆盖 80% 的场景。
- 工具辅助：VS Code 的 Git 图形界面比命令行更直观，适合初学者。
- 团队一致：统一使用同一套流程，比追求'最好'的流程更重要。
- 文档化：把你们的流程写成文档，新同事一看就懂，减少沟通成本。
