Git merge 和 rebase 在整理提交历史时的区别是什么

Git merge 和 rebase 都能合并分支，但 merge 会保留完整的分支合并轨迹，适合公共分支；rebase 会重写历史让记录变直线，适合本地整理提交后再合并。

先说结论：公共分支合并优先用 merge，本地提交整理可用 rebase，严禁对已推送的公共分支使用 rebase。

命令速用版

以下是两种操作的基础命令，执行前请确保工作区干净。

# Merge 方式：将 feature 分支合并到当前分支
git merge feature

# Rebase 方式：将当前分支变基到 main 分支之上
git rebase main

merge 操作会创建一个新的合并提交（merge commit），这个提交有两个父提交，分别指向合并前的两个分支尖端，因此保留了完整的分支演进图形。

rebase 操作则是找到两个分支的共同祖先，将当前分支的提交“复制”并重新应用到目标分支的最新提交之后。这个过程会生成新的提交哈希，使得历史记录看起来是一条直线，没有分叉。

1. 使用 Merge 合并分支

切换到目标分支，执行合并，如有冲突解决后提交。

git checkout main
git merge feature
# 如有冲突，编辑文件解决后
git add .
git commit

2. 使用 Rebase 整理历史

在本地功能分支上，将其变基到主分支最新状态，解决可能出现的多次冲突。

git checkout feature
git rebase main
# 冲突时解决后
git add .
git rebase `--continue`

使用图形化日志命令查看提交历史结构。

git log `--graph` `--oneline` `--all`

merge 后能看到明显的分叉汇合线条和 merge commit；rebase 后提交记录呈单一直线，无额外合并节点。

Rebase 过程中若遇到复杂冲突或想放弃操作，可使用以下命令恢复。

1. 放弃变基

如果在 rebase 过程中发现冲突过多或操作失误，可立即终止变基，回到操作前的状态。

git rebase `--abort`

2. 找回丢失提交

若 rebase 完成后发现提交丢失，可通过 reflog 查找操作前的 HEAD 指针位置并重置。

# 查看操作历史日志
git reflog
# 找到变基前的 commit id，例如 abc1234
git reset `--hard` abc1234

1. 公共分支严禁 Rebase：一旦对已推送到远程的公共分支（如 main/master）执行 rebase，会改变提交哈希，导致其他同事拉取代码时出现严重冲突或历史混乱。

2. 冲突解决次数不同：merge 通常在合并点解决一次冲突；rebase 可能在每个提交应用时都触发冲突，需要多次执行 git rebase `--continue`。

3. 历史丢失风险：rebase 会丢弃原来的提交对象（虽然暂时可找回），如果操作失误且未备份，可能导致代码丢失。