vue项目git工作流核心是分支策略、提交规范与代码审查：main仅接受release/hotfix合并，develop为开发主干，feature/bugfix/hotfix/release分支各司其职；提交须用conventional commits格式，如feat(auth): add login;通过husky+lint-staged+commitlint自动化拦截；pr需附验证说明，双人审查且禁用force push。
Vue 项目要跑得稳、协作顺，Git 工作流不能靠“凭感觉”。核心是三件事：分支怎么分、代码怎么交、问题怎么审。下面直接说落地用得上的要点。
分支策略：按角色明确生命周期
主流 Vue 项目（如 vue-admin-better、芋道后台）普遍采用 GitFlow 衍生模型，关键不在分支多，而在职责清晰：
- main：只存可上线代码，禁止直接提交，只接受 release 或 hotfix 的合并
- develop：日常开发主干，所有功能最终合入这里，保持可测试但未必可发布
-
feature/xxx：从 develop 拉出，完成即删；命名带业务含义，比如
feature/order-export -
bugfix/xxx：修复已知缺陷，目标分支为 develop；紧急线上问题走
hotfix/xxx，直合 main + develop - release/vx.x.x：仅用于版本封版，只做 bug 修复和版本号更新，不加新逻辑
提交信息：让每次 commit 都能自解释
模糊的 “update” 或 “fix” 提交会拖慢所有人——查问题、写日志、回滚都卡在这里。Vue 生态推荐 Conventional Commits 格式：
- 格式统一为：
<type>(<scope>): <subject></subject></scope></type> - 常用 type：feat（新功能）、fix（缺陷修复）、refactor（重构）、docs（文档）、chore（工具/依赖）
- scope 建议限定模块，如
auth、user-table、api-client - body 和 footer 可选，但涉及 breaking change 或关联 issue（如
Closes #123）建议写明
自动化拦截：把规范卡在代码进仓库前
靠人提醒不如靠工具拦截。vue-element-admin 和现代 Vue3 脚手架都默认集成这类链路：
- 用 Husky 绑定
pre-commit钩子，触发代码检查 - 用 lint-staged 只对暂存区文件运行 ESLint + Prettier，自动修复并重新 add
- 用 @commitlint/cli 校验 commit message 是否符合约定，不合规直接拒绝提交
- CI 流程中再跑一遍全量检查，作为兜底
代码审查：聚焦价值，而非格式
PR 不是过场，是质量守门。团队执行时建议明确几条硬线：
- 提交前必须通过本地单元测试，且 ESLint / Prettier 无报错
- PR 描述需说明“改了什么、为什么改、怎么验证”，附截图或录屏更佳
- Reviewer 至少两人，一人侧重逻辑与边界，一人关注性能与安全（如 XSS、权限校验）
- 拒绝 force push —— 修改反馈后应新增 commit，保留演进痕迹供追溯
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
