如果本文帮助到了你，欢迎[点赞、收藏、关注]哦~
这三个确实非常像，以至于对于初学者来说比较难理解。
总结对比
先给出对比：
特性 |
|
|
|
功能 | 合并分支，保留历史 | 重新应用提交，使历史线性化 | 挑选特定提交，复制到另一个分支 |
提交顺序 | 保留分支的分叉和合并点 | 改变提交顺序，使历史线性化 | 不改变提交顺序，仅复制指定提交 |
哈希值 | 不改变原始提交哈希值 | 改变原始提交哈希值 | 生成新的提交哈希值 |
历史清晰度 | 保留分支历史，适合多人协作 | 线性化历史，适合个人开发 | 灵活挑选提交，但可能使历史复杂 |
适用场景 | 合并分支，保留完整历史 | 更新分支，清理提交历史 | 将特定修复或功能应用到其他分支 |
可视化结果 | |||
是否创建新提交 | 创建合并提交（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 feature2. git rebase 示例
# 切换到 feature 分支
git checkout feature
# 将 feature 分支的提交重新应用到 main 分支
git rebase main3. git cherry-pick 示例
# 切换到 main 分支
git checkout main
# 挑选 feature 分支上的提交 E
git cherry-pick E
