企业官网建设流程全解析

🎯 版本：v1.0 >📅 最后更新：2026.6.4 >🧑‍💻 适用团队：研发团队（前端 & 后端）

🎯 目标

为保障代码质量、协作效率与发布稳定性，制定统一的 Git 分支管理、提交规范和代码合并流程。 所有团队成员必须遵循本规范进行日常开发。

🌲 分支策略

我们采用Git 分支模型，主要包含以下三条核心分支：

🧩 开发流程（标准步骤）

1️⃣ 创建功能分支

从 main创建自己的功能分支。

# 切换到 main 并拉取最新 git checkout main git pull origin main ​ # 创建并切换到新功能分支（命名规范见下文） git checkout -b feature/your-task-name

📌说明：

• 分支名应清晰表达功能或任务内容，如feature/sla-display-rule。

• 所有开发工作在功能分支上完成。

2️⃣ 开发与提交代码

在功能分支上进行开发，定期提交代码。

# 添加修改文件 git add . ​ # 提交代码（使用规范提交信息） git commit -m "feat: 新增 S5 SLA 显示逻辑" git push origin feature/your-task-name

✅提交信息规范（Conventional Commits）：

📌 示例：

feat: 登录页面增加验证码输入框 fix: 修复事件台账更新时间显示错误 refactor: 优化 SLA 计算逻辑

⚠️每次提交必须是自己修改的代码，禁止提交他人代码而不注明。

3️⃣ 合并到develop（测试流程）

功能开发完成后，合并到develop进行集成测试。

# 切换回 develop git checkout develop git pull origin develop ​ # 合并功能分支（保留合并记录） git merge --no-ff feature/your-task-name ​ # 推送至远程 git push origin develop

📌 说明：

• 此操作由开发者自行完成（需有权限）。

• 测试人员将在develop环境进行验证。

❗禁止行为：不要在自己的功能分支上执行git merge develop，避免引入未测试代码。

4️⃣ 向main发起合并请求（MR）

测试通过后，向main分支发起合并请求。

1. 登录 Git 平台（如 GitLab / GitHub / Gitee）。

2. 创建Merge Request（MR）：

   • 源分支：feature/your-task-name

   • 目标分支：main

3. 填写 MR 标题、描述，关联任务编号（如 Jira ID）。

4. 添加 reviewer 进行代码审查。

5. 等待 CI/CD 检查通过后，由有权限的人员合并。

✅MR 要求：

• 必须有明确的变更说明。

• 必须通过代码审查。

• 必须关联项目任务编号。

5️⃣ 同步main到功能分支（可选）

如果功能分支仍需继续开发，可拉取main最新代码。

# 切换到功能分支 git checkout feature/your-task-name ​ # 拉取 main 分支最新代码 git pull origin main

📌 说明：

• ✅ 允许从main合并到功能分支（用于同步最新主干）。

• ❌ 禁止从develop合并到功能分支（避免污染）。

🚫 禁止行为

🏷️ 分支命名规范

🧰 最佳实践建议

• 定期清理已合并的远程功能分支。

• 提交前先pull最新代码，减少冲突。

• 使用.gitignore忽略node_modules、.env等敏感/临时文件。

• 提交前本地测试通过，避免阻塞 CI/CD。

📎 附录：流程图（文字版）

[开始开发] ↓ [从 develop 创建 feature/xxx 分支] ↓ [开发功能 → 提交代码 → 推送] ↓ [测试通过 → 合并到 develop] ↓ [发起 MR: feature/xxx → main] ↓ [代码审查通过 → 合并到 main] ↓ [部署研发环境]