WR王锐.dev
管理
← 博客
技术2026-09-059 次阅读

Git/Gitee 工作流实战：MES 项目如何规范管理代码分支与评审

# Git# Gitee，工作流，代码评审，MES，持续集成

背景：为什么 MES 项目 Git 管理总出问题

MES 系统上线两年，代码库从 2 万行涨到 15 万行，Git 分支从 master 一个分支发展到十几条功能分支，问题也越来越多：

  • 产线紧急修复 直接改 master，第二天回滚发现改错了地方，工单数据全乱套；
  • 多人并行开发 同一文件不同人改，合并时冲突到怀疑人生；
  • 版本追溯 "这功能上个月改过，到底哪个版本"——查半天 git log 。

问题不在 Git 本身，在工作流不规范。MES 项目不是个人练习，是团队协作、多产线交付、持续集成，需要一个能扛住压力的 Git 工作流。

解决思路：Gitee + Git Flow 混合模式

我的做法是：分支规范 → 提交规范 → 代码评审 → CI/CD 联动，四条线齐头并进。

选型 Gitee 的原因：内网部署、支持私有库、与国产 IDE 兼容性好、支持 Webhook 触发 CI 任务。

第一步：分支结构设计

采用 Git Flow 简化版，去掉 Release/Hotfix 的复杂分支，保留核心：

master          → 生产环境代码，随时可发布
develop         → 开发主分支，每日合并功能分支
feature/*       → 功能开发分支，如 feature/mes-station-query
hotfix/*        → 紧急修复分支，如 hotfix/station-save-bug
release/*       → 预发布分支，如 release/v2.1.0

分支保护规则（Gitee 后台配置）：

  • master、develop 禁止直接 push，必须通过 Pull Request；
  • PR 必须至少有 1 人 code review 才能合并；
  • master 合并后自动打 tag，触发打包部署。

第二步：提交信息规范

MES 项目团队多人协作，提交信息不统一，git log 像天书。统一用 Conventional Commits 规范：

feat: 新功能
fix: 修复 bug
docs: 文档变更
style: 代码格式（不影响逻辑）
refactor: 重构（无新功能、无 bug 修复）
test: 测试相关
chore: 构建/工具相关

# 示例
feat(station): 增加工站状态筛选功能
fix(report): 修复日报良率计算精度丢失
docs(api): 更新设备对接接口文档

提交信息长度不超过 50 字，正文详细描述（如需要），并关联 Issue 编号：

feat(station): 增加工站状态筛选功能

- 新增状态下拉选择
- 添加筛选 API 接口

Closes #42

团队约定：PR 标题就是提交信息，合并时 Squash Commit，避免 PR 里塞十几条提交。

第三步：代码评审流程

MES 项目代码评审（Code Review）是质量门禁，流程如下：

  1. 开发者创建 PR：从 feature 分支指向 develop，填写 PR 模板（变更内容、测试说明、影响范围）；
  2. 自动检查：Webhook 触发 CI 流水线，运行单元测试、静态扫描（SonarQube）、代码格式检查；
  3. 评审人分配：至少 1 名资深开发者 +1 名领域负责人（如 MES 业务负责人）；
  4. 评审意见：评论代码问题，评论需明确（如"这里缺少空值判断"而非"优化一下"）；
  5. 修复并合并：开发者修复后重新推送，评审人确认通过后合并。

评审清单（评审人必查项）：

  • 代码逻辑是否正确？边界条件是否处理？
  • 是否有性能隐患（如 N+1 查询、内存泄漏）？
  • 是否有安全风险（SQL 注入、权限校验）？
  • 是否符合团队规范（命名、注释、日志）？
  • 单元测试是否覆盖？覆盖率是否达标？

第四步：CI/CD 联动

Git 工作流不是孤立的，要和 CI/CD 联动才能发挥威力：

# Gitee 仓库 → 代码托管
│
├─ PR 合并到 develop
│  └─ 触发 CI 流水线
│     ├─ 拉取最新代码
│     ├─ 安装依赖（dotnet restore）
│     ├─ 编译项目（dotnet build）
│     ├─ 运行单元测试（dotnet test）
│     ├─ 静态代码扫描（SonarQube）
│     └─ 失败则通知开发者
│
└─ PR 合并到 master
   └─ 触发部署流水线
      ├─ 打版本号 tag（v1.0.0）
      ├─ 打包发布（dotnet publish）
      ├─ 上传镜像（Docker）
      └─ 部署到生产环境（K8s/IIS）

MES 项目用的是 Gitee + Jenkins：Gitee 负责代码托管和 PR 管理，Jenkins 负责 CI/CD 流水线。Webhook 配置在 Gitee 后台，监听 Push 和 PR 事件。

踩坑记录：四个真实案例

坑 1：feature 分支没及时合并

一个功能开发两周没合并，develop 变了十几版，合并时冲突爆炸。解决方案：每日至少 pull develop 一次，保持 feature 分支与 develop 同步。

坑 2：commit message 不规范

早期提交信息五花八门：update、fix bug、test，后期无法追溯变更原因。引入 commitlint 工具，提交时自动校验格式，不符合规范拒绝提交。

坑 3：PR 评审流于形式

早期为了赶进度，PR 评审就是点"Approve"，问题代码直接上生产。后来改成强制评审规则：评审意见必须至少一条，否则无法合并；每周统计评审覆盖率，纳入绩效考核。

坑 4：大文件上传到 Git

有人把产线采集的 Excel、图片上传到仓库，Git 体积从 500MB 涨到 20GB。解决方案：使用 Git LFS（Large File Storage），配置 .gitattributes 文件，大文件走 LFS，Git 只存指针。

# .gitattributes
*.xlsx filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text

进阶：分支保护策略模板

Gitee 后台配置分支保护时，可以参考这个模板：

分支：master
- 禁止直接 push
- 必须通过 Pull Request
- PR 至少 2 人批准
- CI 流水线必须通过
- 不允许 force push

分支：develop
- 禁止直接 push
- 必须通过 Pull Request
- PR 至少 1 人批准
- CI 流水线必须通过

分支：feature/*
- 允许开发者自己 push
- 合并前必须通过 CI

总结

MES 项目的 Git 工作流核心是规范 + 自动化：

  • 分支规范：Git Flow 简化版，master/develop/feature/hotfix 各司其职；
  • 提交规范：Conventional Commits，PR 标题即提交信息；
  • 评审流程：强制评审、清单检查、统计覆盖；
  • CI/CD 联动：PR 触发自动检查，master 触发自动部署。

按这个工作流走，MES 项目代码质量明显提升：冲突减少 80%、回滚减少 90%、版本追溯从半天到分钟级。Git 不是装样子，是工程化的基石——用好它，团队效率直接上一个台阶。

附：Git 工作流检查清单

  • 分支是否按规范创建？（feature/*、hotfix/*）
  • 提交信息是否符合规范？（feat/fix/docs 等）
  • PR 是否经过评审？（至少 1 人批准）
  • CI 流水线是否通过？（单元测试、静态扫描）
  • 是否有大文件上传？（检查 Git LFS）
  • 分支保护策略是否配置？（禁止直接 push）
  • 每周是否有代码评审覆盖率统计？

——工程师写给工程师：Git 工作流不是束缚，是保护。规范越清晰，团队越高效。

评论 (0)