Git 工作流与分支管理实战：rebase vs merge 对比、冲突解决、规范 Commit Message 与主干稳定性最佳实践

1. 版本控制与协作流程（Git 工作流、分支管理、合并冲突）

• 虽然 Git 用得多，但“rebase vs. merge”、如何解决冲突、如何编写规范的 commit message、如何维护主干的稳定性，都需要一段时间才能形成体系化的理解。

摘要

在日常团队协作开发中，Git 是不可或缺的工具。然而，随着项目复杂度的提升，如何在多人协作环境下保持主干稳定性、合理地管理分支、解决合并冲突以及编写规范的提交信息，成为摆在开发者面前的现实问题。本文将通过一个典型的开发场景展开，从环境配置到工作流设计，再到冲突解决和最佳实践，逐步构建一个系统化的理解。

@[toc]

---

1 开发场景介绍

在一个中大型的微服务项目中，团队成员往往并行开发多个功能。此时问题频频出现：

• A 开发者和 B 开发者同时修改了 user_service 的接口文件，最终提交时发生冲突。
• 团队对 git merge 和 git rebase 的使用意见不统一，导致提交历史混乱。
• 主干分支偶尔出现“坏代码”，影响了后续 CI/CD 部署。

“Git 本身并不复杂，复杂的是人和团队如何用好它。”

---

2 开发环境说明

下表展示了本文的实验环境：

工具/环境	版本	说明
Git	2.42+	核心版本控制工具
IDE	VSCode / IntelliJ	提供 Git 插件支持
CI/CD	GitHub Actions / Jenkins	自动化测试与部署
操作系统	Ubuntu 22.04 / macOS	开发环境

---

3 Git 工作流设计

一个合理的工作流能减少 70% 的冲突。常见的两种模式：

3.1 Git Flow

• master：生产稳定分支
• develop：开发主干
• feature/*：新功能开发
• release/*：发布准备
• hotfix/*：紧急修复

3.2 GitHub Flow

• 只有一个长期存在的 main 分支
• 每个功能分支从 main 拉出
• 合并必须通过 PR 和 Review

---

4 rebase vs. merge

在合并分支时，rebase 与 merge 经常让人困惑：

• merge 保留分支历史，但会产生“叉路”提交。
• rebase 重写提交历史，让历史更线性，但需要谨慎使用。

建议：公共分支用 merge，个人分支可用 rebase 整理提交历史。

---

5 冲突解决实战

冲突不可避免，但解决方式可控。

场景：

• dev 分支中修改了 api/user.js 第 10 行返回 JSON。
• feature/profile 分支中在同一行修改了字段结构。

解决步骤：

1. 执行 git pull origin dev → 发生冲突
2. 使用 git status 查看冲突文件
3. 打开文件，手动修改：

<<<<<<< dev
return { id: user.id, name: user.name };
=======
return { id: user.id, name: user.name, avatar: user.avatar };
>>>>>>> feature/profile

4. 修改为合并后的最终版本：

return { id: user.id, name: user.name, avatar: user.avatar };

5. 执行 git add . && git rebase --continue

---

6 编写规范的 Commit Message

一个清晰的提交信息，有助于后续排查问题与代码回顾。

常见规范（Angular 规范）：

<type>(scope): <subject>

示例：

feat(user): add avatar support
fix(api): resolve null pointer exception
docs(readme): update installation guide

提示：使用 commitlint + husky 可以在提交阶段自动校验信息格式。

---

7 保持主干稳定性的最佳实践

• 所有提交必须通过 CI/CD 测试 才能合并到主干。
• 使用 保护分支（Protected Branch） 功能，避免直接推送到 main。
• 严格执行 Code Review，至少两人通过才能合并。

---

8 总结

Git 本身功能强大，但如果没有清晰的协作流程和规范，项目就会陷入“冲突地狱”。
本文从开发环境、工作流设计、rebase 与 merge 的取舍，到冲突解决与提交规范，给出了一个系统化的实践指南。

未来团队可以继续优化：

• 引入 Git Hooks 自动检查提交代码质量
• 借助 GitOps 将 Git 作为运维的唯一可信源

---