在团队协作中，我们经常需要将功能分支（feature branch）合并回主分支（main/master）。
而在这个过程中，最常见的两种方式是 merge 和 rebase。
本文将通过实际命令示例，介绍这两种方式的完整工作流，并对比它们的优缺点。
一、常规工作流：使用 merge 合并
在多人协作中，主分支 (main) 通常会持续更新，因此功能分支 (feature-branch) 在开发过程中需要定期同步主分支的最新代码，以避免冲突集中爆发。
步骤一：在功能分支上解决冲突
# 切换到功能分支
git checkout feature-branch
# 获取远程最新代码
git fetch origin
# 合并主分支的更新到功能分支
git merge origin/main
此时，如果有冲突，Git 会提示你手动解决。解决完冲突后执行：
git add .
git commit -m "Resolve conflicts with main"
步骤二：合并回主分支
当功能开发完成并测试通过后，将分支合并回主分支：
# 切换到主分支并更新
git checkout main
git pull origin main
# 合并功能分支（使用 --no-ff 保留独立的合并记录）
git merge --no-ff feature-branch -m "Merge feature-branch"
--no-ff 参数的作用是：
即使可以快进（fast-forward）合并，也会生成一个新的合并提交，
从而在提交历史中保留分支的独立性，方便追踪。
步骤三：推送到远程
git push origin main
主分支更新完成，功能分支的生命周期到此结束，可以选择删除：
git branch -d feature-branch
二、进阶方式：使用 rebase 代替 merge
相比 merge，rebase（变基）可以让提交历史更加线性和干净。
它会将功能分支上的提交“重新播放”在主分支最新提交之后，
从而避免出现额外的“合并节点”。
步骤一：在功能分支上变基
# 切换到功能分支
git checkout feature-branch
# 获取远程最新代码
git fetch origin
# 将当前分支变基到主分支最新提交之上
git rebase origin/main
如果在变基过程中出现冲突，按照提示手动解决，然后执行：
git add .
git rebase --continue
直到 rebase 过程顺利完成。
步骤二：合并回主分支（快进合并）
当功能分支已经基于主分支最新提交，合并时通常不再需要生成额外的合并提交：
git checkout main
git merge feature-branch
由于历史已经是线性的，这次合并通常是“快进合并”（fast-forward merge），
不会新增一个合并节点。
三、Merge 与 Rebase 的区别
| 对比项 | merge | rebase |
|---|---|---|
| 提交历史 | 保留分支节点，可能出现“分叉” | 提交历史线性化 |
| 冲突次数 | 冲突在合并时一次性集中解决 | 每次变基都可能触发冲突 |
| 可追溯性 | 更清楚地保留分支合并点 | 历史更整洁，但合并点被抹平 |
| 适用场景 | 团队协作、保留分支结构 | 个人或短期分支 |
五、总结
merge强调分支独立性与可追溯性。rebase强调历史整洁与线性可读性。- 在实践中，团队通常会在开发阶段使用 rebase 同步主分支，
在最终合并时使用 merge 保留分支记录。
掌握这两种方式的使用场景，可以让你的 Git 历史既清晰又高效。
