企业官网建设流程全解析

在日常开发中，我们经常会遇到这样的情况：
一个功能分支上反复提交了很多零碎 commit（如“优化提示词”“调整参数”“修复小问题”），
但合并到 master 时，希望只留下 1 条干净、有语义的提交记录。

本文结合真实场景，介绍最推荐、最安全的做法。

一、问题背景

我在refactor-prompt分支上，提交了大量零碎 commit，例如：

• 优化提示词
• 新增智能助手 SSE 接口
• 修改接口响应类型为 SSE
• 移除测试接口
• 调整参数
• 优化 tools 名称

这些提交在功能开发阶段是非常合理的，但如果直接 merge 到master，会导致：

• master 提交历史非常杂乱
• 很多 commit 信息重复、没有语义
• 回滚、审计、Code Review 成本上升

所以：

我们把refactor-prompt的所有改动合并到master的时候，
建议 master 上只保留 1 条提交记录。

二、最推荐方案：git merge --squash

这是我个人最推荐、也是团队中最常用的方案。

为什么选 squash merge？

• ✅ 不改分支历史（安全）
• ✅ 不需要 force push
• ✅ master 提交历史干净
• ✅ 非常适合功能分支 → 主分支

三、完整操作步骤（一步步来）

1️⃣ 切换到 master 分支

git checkout master

2️⃣ 确保 master 是最新的（很重要）

git pull origin master

3️⃣ 使用 squash 合并分支

git merge --squash refactor-prompt

这一步做了什么？

• 把refactor-prompt上的所有改动
• 一次性应用到master
• 不会生成任何 commit
• 改动会全部处于「已暂存（staged）」状态

4️⃣ 手动提交为一条记录

git commit -m "feat: 智能助手-小美 SSE 接口与提示词优化"

你可以根据项目实际情况，自定义一条语义清晰的提交信息。

5️⃣ 推送到远程 master

git push origin master

6️⃣ （可选）删除功能分支

如果分支已经完成使命：

git branch -d refactor-prompt git push origin --delete refactor-prompt

四、最终效果

✅master分支上：

• 只有1 条提交
• 提交信息清晰、可读
• 历史干净、可维护
  

✅refactor-prompt分支上：

• 仍然保留原始开发过程
• 不影响问题定位和回溯

五、对比另一种方案（相对不推荐）

方案：git rebase -i压缩提交

这种也能做到“只留一条提交”，但存在问题：

• ❌ 会修改分支历史
• ❌ 已 push 的分支需要git push -f
• ❌ 多人协作时容易出事故

建议：

功能分支合并到 master：优先使用merge --squash

六、一些建议

1️⃣ 功能分支可以随便提交

开发过程中：

• commit 可以频繁
• commit 信息可以偏“过程化”
• 不必过度纠结

2️⃣ master 分支必须“像日志一样干净”

master 上的 commit 应该做到：

• 一条 commit = 一个完整业务改动
• 能被产品 / 运维 / 未来的自己看懂
• 能随时回滚

七、推荐的提交信息规范（示例）

feat: 智能助手-小美 SSE 接口 refactor: 优化提示词与 tool 定义 fix: 修复 SSE 流式响应中断问题 chore: 移除测试接口