转载请注明出处：小锋学长生活大爆炸[xfxuezhagn.cn]

如果本文帮助到了你，欢迎[点赞、收藏、关注]哦~

这三个确实非常像，以至于对于初学者来说比较难理解。

总结对比

先给出对比：

特性	git merge	git rebase	git cherry-pick
功能	合并分支，保留历史	重新应用提交，使历史线性化	挑选特定提交，复制到另一个分支
提交顺序	保留分支的分叉和合并点	改变提交顺序，使历史线性化	不改变提交顺序，仅复制指定提交
哈希值	不改变原始提交哈希值	改变原始提交哈希值	生成新的提交哈希值
历史清晰度	保留分支历史，适合多人协作	线性化历史，适合个人开发	灵活挑选提交，但可能使历史复杂
适用场景	合并分支，保留完整历史	更新分支，清理提交历史	将特定修复或功能应用到其他分支
可视化结果	https://learngitbranching.js.org/?NODEMO=&locale=zh_CN	https://learngitbranching.js.org/?NODEMO=&locale=zh_CN	https://learngitbranching.js.org/?NODEMO=&locale=zh_CN
是否创建新提交	创建合并提交（merge commit）	重新应用提交，生成新的提交	复制指定提交，生成新的提交
是否修改历史	不修改历史	修改历史，重新应用提交	修改历史，复制指定提交
冲突处理	合并冲突，解决后完成合并	逐个解决冲突，继续变基	逐个解决冲突，继续挑选提交

可视化理解

假设我们有以下的提交历史：

A -- B -- C [main]\D -- E [feature]

• main 分支包含提交 A、B 和 C。

• feature 分支从 main 的 B 提交分叉，包含提交 D 和 E。

1. 使用 git merge

如果我们在 main 分支上运行 git merge feature，Git 会创建一个新的合并提交，将 feature 分支的更改合并到 main 分支。

可视化结果：

A -- B -- C -- F [main]\       /D -- E [feature]

• F 是一个新的合并提交，表示 main 和 feature 分支的合并。

• 提交历史保留了分支的分叉和合并点，适合多人协作场景。

---

2. 使用 git rebase

如果我们在 feature 分支上运行 git rebase main，Git 会将 feature 分支的提交 D 和 E 重新应用到 main 分支的最新提交 C 上。

可视化结果：

A -- B -- C [main]\D' -- E' [feature]

• 提交 D 和 E 被重新应用到 C 上，生成了新的提交 D' 和 E'。

• 提交历史变得更加线性，适合个人开发或清理提交历史的场景。

---

3. 使用 git cherry-pick

假设我们只想将 feature 分支上的提交 E 应用到 main 分支，可以在 main 分支上运行 git cherry-pick E。

可视化结果：

A -- B -- C -- E' [main]\D -- E [feature]

• 提交 E 被复制到 main 分支上，生成了新的提交 E'。

• 提交历史中只包含了被挑选的提交，适合将特定修复或功能应用到另一个分支的场景。

---

个人理解

• git merge 适合大部分情况，谁拉取了、做了几次提交、合并到了什么位置等，都非常清晰；
• git rebase 适合个人开发者。虽然它能把记录拉成一条直线，但对于团队开发而言，在看谁修改了哪部分的时候就懵逼了，非常不直观；
• git cherry-pick 适合在分支上做了一系列修改，不想把这么多提交都放到主分支上去的时候用。只需要把分支上最终的提交拿到主分支就可以了。也比较清晰。

因此，我觉得: merge > cherry-pick >> rebase

操作示例

1. git merge 示例

# 切换到 main 分支
git checkout main# 合并 feature 分支
git merge feature

2. git rebase 示例

# 切换到 feature 分支
git checkout feature# 将 feature 分支的提交重新应用到 main 分支
git rebase main

3. git cherry-pick 示例

# 切换到 main 分支
git checkout main# 挑选 feature 分支上的提交 E
git cherry-pick E