第3篇：实操落地篇 · 3套企业标准工作流（IDEA可视化版）
- 前言
- 前置：工作流快速识别
-
- 工作流一：Merge安全工作流（新人首选·零风险）
- [工作流二：Trunk-Based 主干开发（Rebase版·互联网主流）](#工作流二：Trunk-Based 主干开发（Rebase版·互联网主流）)
- [工作流三：Git-Flow 重型分支模型（多版本维护专用）](#工作流三：Git-Flow 重型分支模型（多版本维护专用）)
- 非规范模式警示：常驻dev单分支模式
前言
本文覆盖国内企业最常用的3套标准协作工作流，所有步骤均为经过业界验证的最优实践，精准对应IDEA图形化操作入口，标注易错点与风险边界，新人可直接照着执行，全程零协作事故。
前置：工作流快速识别
查看远程仓库的常驻分支，10秒即可判断团队采用的协作规范：
- 仅
main一条常驻主干 → 主干开发模式（Trunk-Based） - 同时存在
main+develop两条常驻主干 → Git-Flow重型模式
工作流一：Merge安全工作流（新人首选·零风险）
适用场景：所有多人协作项目、新人过渡期、求稳优先的中小型团队；全程无历史改写风险，适配90%以上的通用开发场景。
标准操作步骤（IDEA版）
-
新建功能分支
切换至本地
main分支，执行顶部菜单Git → Fetch刷新远程状态，再执行Git → Pull同步最新主干代码；基于最新main新建功能分支，命名遵循feature/功能标识规范。 -
本地开发提交
在功能分支内编码，完成独立功能块后执行提交；遵循小粒度频繁提交原则，禁止攒大量改动一次性提交，便于后续问题定位与回滚。
-
同步远程主干（最优方案·无需切换分支）
全程停留在功能分支，在右下角分支面板找到远程跟踪分支
origin/main，右键选择「Merge into Current」。- IDEA会自动同步远程最新状态并执行合并
- 出现冲突则在冲突编辑器中解决，确认代码逻辑无误后点击应用
替代方案（老式中转法·不推荐）：先切换本地
main执行Pull更新，再切回功能分支合并本地main。缺点是步骤繁琐，若忘记更新本地main，会合并过时的旧代码，导致冲突白解决。 -
自测与推送
本地启动项目完整验证功能正常后，执行
Git → Push将功能分支推送至远程仓库。 -
提交PR评审
在代码托管平台（Gitee/GitHub/GitLab）发起PR合并请求，申请将功能分支合入
main主干，指派同事进行代码评审。 -
收尾清理
PR合并通过后，删除远程功能分支；本地切换回
main分支同步最新代码，删除本地废弃功能分支。提示：部分平台支持合并后自动删除远程分支，本地可通过Fetch时勾选「Prune stale remote branches」清理过期引用。
工作流二：Trunk-Based 主干开发（Rebase版·互联网主流）
适用场景：互联网敏捷团队、Java后端项目；是当前业界标准协作模式，追求整洁的线性提交历史，适配高频迭代、频繁上线的业务。
分支架构规则
- 唯一常驻主干：
main，存放经代码评审、可直接上线的稳定代码 - 所有需求均新建短期功能分支，生命周期随需求结束而终止
- 合并以Rebase为主，保持主干提交历史线性整洁
标准操作步骤（IDEA版）
-
每日开工同步
切换至本地
main分支，执行Fetch刷新远程状态，执行Pull（合并策略选择Rebase）同步远端最新主干代码。 -
新建功能分支开发
基于最新
main新建功能分支，编码过程中保持小粒度频繁提交。 -
开发中途同步主干
停留在功能分支，在右下角分支面板右键
origin/main，选择「Rebase onto」，将本地提交逐个变基到最新主干之后；按顺序解决每个提交的冲突，完成变基。⚠️ 安全约束：若该分支已推送远程且有同事共同开发，禁止执行变基，改用Merge方式同步主干。
-
推送与PR评审
本地自测通过后执行推送：
- 分支从未推送过远程：直接正常Push即可
- 分支已推送且仅个人使用：执行强制推送（Force Push）覆盖远程
发起PR评审，代码合入主干后，清理本地与对应远程分支。
工作流三：Git-Flow 重型分支模型（多版本维护专用）
适用场景：传统桌面软件、国企系统、需要长期维护多个线上版本的项目；当前互联网敏捷团队较少采用。
分支架构规则
- 双常驻主干（项目全生命周期永久保留）
main：线上生产环境稳定代码，每次正式发布必须打上版本Tag标签develop：公共开发集成分支，所有新功能优先合入此分支
- 三类临时分支（任务结束后立即删除）
feature/*：业务功能分支，必须从develop拉出 ，开发完成合并回developrelease/*：版本上线前测试分支，从develop拉出，测试通过后同时合入main与develophotfix/*：线上紧急修复分支，必须从main拉出 ，修复完成后同时合入main与develop，并在main上打版本Tag
三大核心流程（IDEA操作逻辑）
-
日常功能开发
切换至
develop分支同步最新代码 → 新建feature分支开发 → 开发完成Merge回develop→ 发起PR评审 → 删除临时分支 -
版本发布流程
从
develop拉出release测试分支 → 测试环境修复缺陷 → 测试通过后同时合并进main和develop→ 在main分支打版本Tag → 正式上线 → 删除release分支 -
线上紧急Bug修复
切换至
main分支同步最新代码 → 新建hotfix分支修复缺陷 → 验证通过后先后合并回main和develop→ 在main新增版本Tag → 删除hotfix分支
非规范模式警示：常驻dev单分支模式
- 模式特征 ：全员在同一条长期
dev分支开发，不创建独立功能分支，整轮迭代完成后统一合并main - 致命缺陷：多需求代码耦合、无法单独上线、紧急修复易夹带未完工代码、多人并行冲突频发、版本回滚难度极高
- 适用范围：仅适合个人Demo项目，企业多人协作严格禁止采用