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分支中在同一行修改了字段结构。
解决步骤：
- 执行
git pull origin dev→ 发生冲突 - 使用
git status查看冲突文件 - 打开文件，手动修改：
<<<<<<< dev
return { id: user.id, name: user.name };
=======
return { id: user.id, name: user.name, avatar: user.avatar };
>>>>>>> feature/profile
- 修改为合并后的最终版本：
return { id: user.id, name: user.name, avatar: user.avatar };
- 执行
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 作为运维的唯一可信源