git merge和git rebase

最新推荐文章于 2025-05-14 11:39:28 发布

江边垂钓者

最新推荐文章于 2025-05-14 11:39:28 发布

阅读量530

点赞数 20

文章标签： git

本文链接：https://blog.csdn.net/2401_86968032/article/details/147931210

版权

在Git中merge和rebase都是git在管理整合分支的两种主要工具，但是他们的工作方式、提交历史影响和使用场景不同。

在这里插入图片描述

定义
- 将两个分支的提交历史合并，创建一个新的合并提交（merge commit），保留两个分支的完整历史。但是在快进合并（fast-foward）情况下直接移动指针，保持线性历史
- 通常是将特性分支（feature branch）合并到主分支（如main分支）
工作原理
- Git首先会找到两个分支的共同祖先节点，计算差异，然后合并代码
- 如果没有冲突，自动合并
- 如果有冲突，需要手动解决该冲突后生成合并提交
- 快进模式：若目标分支无新提交，直接将指针移动到源分支，历史线性。
- 非快进模式：生成合并提交，历史非线性，保留分支拓扑

示例

# 将feature分支合并到main分支上
git checkout main
git merge feature

提交历史图

快进合并（线性历史，修正后在一条直线上）

# 初始：main和feature指向A；feature新增B、C。
# 合并后：main快进到C，历史为单条直线。
A---B---C  (main, feature)

非快进合并（非线性历史）

# 合并后：M为合并提交，指向B和D
A---B  (main)
 \
  C---D  (feature)
       \
        M  (main, 合并提交)

优点
- 快进合并：生成线性历史，干净简单，适合简单整合。
- 非快进合并：保留分支历史，反映开发过程，便于追溯。
- 团队协作：合并提交记录分支整合，适合多人项目。
- 简单冲突处理：冲突集中解决，生成单一提交。
- 非破坏性：不改写历史，安全用于共享分支。
缺点:
- 非快进历史复杂：频繁非快进合并导致历史杂乱，合并提交多。
- 非快进非线性：分支分叉增加历史图复杂度。
- 快进需条件：仅当目标分支无新提交时快进，否则需手动指定–ff。
适用场景
- 团队开发，保留清晰的历史提交记录

在这里插入图片描述

定义
- 将当前分支的提交"嫁接"到目标分支最新提交上，改写历史，始终生成线性历史
- 用于清理本地分支或平滑整合提交
工作原理
- Git将当前分支的提交逐一应用到目标分支最新提交，生成新提交（SHA值变化）
- 冲突需要逐一提交解决，完成后历史性
示例
- ```
git checkout feature
git rebase main
```
结果：feature的提交重放至main最新提交，历史线性。
可快进合并到main
- ```
git checkout main
git merge feature
```
提交历史图示（线性历史）
- ```
A---B---C'---D'  (main, feature)
```
初始：main在A，feature有A—C—D。
重放后：feature变为A—C’—D’，main快进到D’，历史为单条直线。
优点
- 干净线性历史：历史简洁，易于审查和版本管理。
- 简化提交：可整理提交（如git rebase -i合并小提交）。
- 便于快进合并：重放后主分支可直接快进。
- 适合单人开发：清理本地分支，提升提交质量。
缺点:
- 历史重写：改写提交SHA值，破坏共享分支，影响协作。
- 冲突复杂：逐提交解决冲突，工作量可能大。
- 丢失上下文：线性历史隐藏分支来源，追溯困难。
- 高风险：误操作可能丢失提交。
适用场景
- 适合个人开发，可以保留干净的历史提交记录