[JAVA探索之路]带你理解Git工作流程

目录

引言

一、Git核心概念

二、四种主流工作流

中心化工作流

功能分支工作流

GitFlow工作流

Forking工作流

场景选择推荐

三、Git实用工具和小技巧

 Git钩子

急救命令

四、一些小建议

引言

想象一下，你和几个朋友一起写一本小说。如果大家都直接在同一个文档上改，很快就会乱套：有人删了重要情节，有人同时修改同一段落，最后谁也不知道哪个版本是对的。

Git就是解决这个问题的“超级版本管理器”，而工作流程就是大家约定好的“写作规矩”。没有规矩，再好的工具也会用乱。今天，我就带你理清各种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工作流
• 经常紧急上线​ → 功能分支+简单GitFlow

三、Git实用工具和小技巧

 Git钩子

• 提交前自动检查代码格式
• 推送前自动运行测试
• 安装Commitizen，让提交信息更规范

急救命令

# 不小心提交错了？撤销上一次提交但保留修改 git reset --soft HEAD~1 # 查看谁改了哪行代码（甩锅必备） git blame 文件名 # 暂时保存手头工作，去处理紧急bug git stash # 处理完回来继续 git stash pop

四、一些小建议

• 从简单开始：先掌握功能分支工作流，够用80%的场景
• 工具辅助：用VS Code的Git图形界面，比命令行直观
• 团队一致：团队统一用同一套流程，比用“最好”的流程更重要
• 文档化：把你们的流程写成文档，新同事一看就懂

制作不易，如果对你有帮助请点赞，评论，收藏，感谢大家的支持