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

Gitee 工作流实战：Git 分支策略、PR 审核与 Windows Server 自动化部署

# Git# Gitee# 工作流，分支策略# PR 审核，自动化部署# MES# .NET

背景：MES 项目为什么需要规范的 Git 工作流

MES 系统涉及产线工站、设备对接、数据库迁移，代码改动牵一发而动全身。早期我们几个人直接在 main 分支上改代码，结果一次数据库脚本执行失败，整个产线停工两小时。后来引入 Git 分支策略 + Pull Request 审核，才把事故率降下来。

核心问题：MES 系统不是个人项目，是多人协作、多环境部署的工业级应用。如何保证代码质量、追溯改动、快速回滚，需要一套规范的工作流。

解决思路：Git Flow + PR 审核

MES 项目采用简化的 Git Flow 模型：

  • main：生产环境分支，永远稳定，只能通过 PR 合并
  • develop：开发分支，集成所有功能分支的代码
  • feature/*：功能分支，开发新功能时使用
  • hotfix/*：紧急修复分支，直接基于 main 创建
  • release/*：预发布分支，用于上线前的最后测试

配合 Gitee 的 Pull Request 审核机制，确保每次合并都经过至少一人审核。

第一步：本地环境配置

开发机先配置 Git SSH 和 Gitee Token：

# 生成 SSH 密钥（如果还没有）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 添加到 Gitee（网页端 Settings → SSH 公钥）
cat ~/.ssh/id_ed25519.pub

# 配置 Gitee Token（用于 API 调用和自动化脚本）
git config --global url."https://your_token@gitee.com/".insteadOf "https://gitee.com/"

踩坑 1：Windows 换行符问题。在 Windows 上用 VS Code 改过代码，提交到 Linux 服务器运行时报 dos2unix 错误。解决方案：在 .gitignore 里加 .editorconfig，统一使用 LF 换行符：

# .editorconfig
[*]
end_of_line = lf
charset = utf-8

第二步：分支策略与日常开发

日常开发流程：

  1. 从 develop 创建功能分支： 
    git checkout develop
git pull
git checkout -b feature/mes-station-update
  2. 本地开发 + 提交： 
    git add .
git commit -m "feat: 工站列表页增加批量更新功能"
# 提交规范：feat/fix/docs/style/refactor/chore，便于生成变更日志
  3. 推送到 Gitee： 
    git push origin feature/mes-station-update
  4. 创建 Pull Request：在 Gitee 网页创建 PR，从 feature/mes-station-update 合并到 develop，指定一名审核人
  5. 等待审核：审核通过后自动合并，或手动合并

第三步：PR 审核清单

MES 项目规定 PR 审核必须过以下清单：

  • 代码质量：无编译错误、无警告、遵循代码规范
  • 单元测试：核心逻辑有单元测试覆盖
  • 数据库脚本：SQL 脚本已测试、有回滚方案
  • 配置变更：appsettings.json 等配置文件变更已记录
  • 文档更新：接口文档、用户手册是否需要同步更新

踩坑 2：PR 审核被忽视。早期有些 PR 没人审核就合并，结果一个空指针异常把工站列表页搞崩。后来规定：未经审核的 PR 不得合并到 develop，否则追究责任。

第四步：Windows Server 自动化部署

代码合并到 main 后，通过 Windows 计划任务自动拉取并重启应用：

# 1. 在服务器上配置 SSH 密钥（允许自动拉取）
ssh-keygen -t ed25519 -C "deploy-bot"
# 公钥添加到 Gitee 账号的 Deployment Keys（只读权限）

# 2. 创建自动拉取脚本 D:\deploy\pull_and_restart.bat
@echo off
cd D:\webapps\mes-app
git fetch origin
git reset --hard origin/main
dotnet restore
dotnet publish -c Release -o D:\webapps\mes-app\publish
net stop MESApp
net start MESApp
echo Deployment completed at %date% %time% >> D:\deploy\deployment.log

踩坑 3：git reset --hard 导致文件丢失。如果本地有未提交的文件，会被强制覆盖。解决方案：部署脚本里先检查是否有未提交的文件：

if !(git status --porcelain) {
    git fetch origin
    git reset --hard origin/main
    # 继续部署...
} else {
    echo "There are uncommitted changes!"
    exit /b 1
}

踩坑 4：部署期间应用无法访问。直接 net stop 会导致请求中断。改进方案：用 IIS 应用程序池的"回收"功能替代停止/启动，或使用蓝绿部署（两套应用交替切换）。

第五步：数据库迁移管理

数据库脚本不能随便跑，MES 项目采用 migration 版本管理：

  1. 每个迁移脚本命名为：20260831_create_station_table.sql（日期_描述）
  2. 建立 SchemaVersions 表记录已执行的迁移：
CREATE TABLE SchemaVersions (
    VersionId NVARCHAR(50) PRIMARY KEY,
    AppliedAt DATETIME DEFAULT GETDATE(),
    Description NVARCHAR(255)
);
  1. 部署脚本先检查是否已执行过：SELECT * FROM SchemaVersions WHERE VersionId = '...'
  2. 如果未执行，执行迁移脚本并插入记录

踩坑 5：迁移脚本回滚失败。早期迁移脚本只写了 ALTER TABLE，没写回滚脚本。一旦执行失败，无法撤销。解决方案：每个迁移脚本配套一个回滚脚本（如 rollback_20260831_create_station_table.sql），并经过测试。

第六步：版本发布与回滚

MES 项目发布流程：

  1. 创建 release 分支：git checkout -b release/v1.2.0 develop
  2. 在测试环境验证：所有功能、接口、数据库迁移全部测试通过
  3. 合并到 main：git checkout main && git merge release/v1.2.0
  4. 打标签：git tag v1.2.0，推送到 Gitee
  5. 生产环境部署：通过计划任务或手动触发部署脚本
  6. 回滚方案：如果发现问题，git reset --hard v1.1.0 后重新部署

踩坑记录：五个真实案例

  • 坑 1：Windows 换行符跨平台冲突。Windows CRLF + Linux LF，导致脚本执行失败。解决：统一 .editorconfig 配置为 LF。
  • 坑 2：PR 审核被忽视。未经审核的代码直接合并，导致生产事故。解决：强制审核流程，否则追究责任。
  • 坑 3：git reset --hard 导致文件丢失。部署脚本未检查未提交文件。解决：增加文件状态检查逻辑。
  • 坑 4：部署期间应用无法访问。直接停止/启动导致请求中断。解决：用 IIS 应用池回收或蓝绿部署。
  • 坑 5：数据库迁移回滚失败。迁移脚本缺少回滚逻辑。解决：每个迁移配套回滚脚本并测试。

总结

MES 项目的 Git 工作流核心要点：分支策略规范、PR 审核必过、自动化部署、数据库迁移版本化。

  • 分支管理：main/develop/feature/hotfix/release 分工明确，禁止直接改 main
  • PR 审核：至少一人审核，过清单才能合并
  • 自动化部署：Windows 计划任务拉取代码 + 重启应用，减少人工干预
  • 数据库迁移：版本化管理，有回滚方案，经过测试

附：Git 工作流检查清单

  • 功能分支是否从 develop 创建？
  • 提交信息是否符合规范？
  • PR 是否经过至少一人审核？
  • 数据库脚本是否有回滚方案？
  • 部署脚本是否检查未提交文件？
  • 版本号是否打标签？

按这个清单执行，MES 项目的代码质量和管理效率能提升一个台阶。Git 不是为了炫技，而是为了让团队协作更顺畅、事故更少、恢复更快。

评论 (0)