Git 分支整合策略详解：Cherry-pick、Merge、Rebase
在日常的 Git 多分支协作开发中，代码合并是常见操作。Git 中主要提供以下三种方式来合并或迁移分
支的提交：
Cherry-pick：精确挑选部分提交复制到当前分支；
Merge：将整个分支（所有提交）合并到当前分支，产生合并提交；
Rebase：将另一个分支的提交“线性重演”到当前分支之上，不产生合并提交。
这三种操作都可以完成“将代码从一个分支带到另一个分支”的目的，但执行方式、提交历史表现、
适用场景和潜在风险各不相同。
一、Cherry-pick：精准迁移指定提交
1. 核心概念
Cherry-pick 允许从其他分支挑选出特定的提交，并将其复制到当前分支。这会在目标分支上生成一个
新的 commit，对应的哈希值与原分支不同。
适用于：
想要“零星地”带来某几个功能或补丁，而无需合并整条分支。
提前将某个重要修复或特性放到其他分支单独上线。
2. 常用场景
紧急修复：修复 Bug 提交在 dev 上，但必须马上放到 master 发布。
部分功能“偷跑”：分支里功能较多，但只需复制其中 1-2 个提交到主分支或其他特性分支。
3. 特点与优缺点
优点：
精准度高：只拷贝所需的提交，不会引入其他无关改动。
不影响原分支结构：Cherry-pick 不会改写源分支历史，它仅在目标分支上生成新的提交。
缺点：
可能导致重复提交：如果后来合并整个分支（其中包含了这些提交），就会出现重复或冲突。
需要记得在提交信息中注明来源（可用 -x 参数），否则会丢失跟踪信息。
4. 典型命令
# 将某个commit复制到当前分支
git cherry-pick <commitHash>
# 一次性复制多个提交
git cherry-pick <HashA> <HashB>
# 复制从A到B的一系列提交（不包含A）
git cherry-pick A..B
二、Merge：合并整个分支
1. 核心概念
Merge 是将一个分支所有历史提交整体合并到当前分支，形成一个新的 merge commit（合并提交），
该提交拥有多个父提交。
适用于：
开发完成后，将功能分支整体合并到主分支；
与多人协作时，保留完整的分支历史。
2. 常用场景
大多数团队协作的默认操作：新功能在 feature 分支开发完成后，git merge feature 合并到 master/dev。
保留分支分叉痕迹：需要在提交历史中明确什么时候进行合并、由谁合并，以及保留所有分支的变动源头。
3. 特点与优缺点
优点：
不改写任何已有提交：历史提交哈希不会改变，更利于多人协作。
提交记录完整：时间轴能保留实际分叉和合并情况。
缺点：
提交历史不够线性：合并多了会产生多条分叉，在提交图中较复杂。
每次合并会产生一个 Merge Commit，若非常频繁，历史会看起来臃肿。
4. 典型命令
# 在当前分支上合并其他分支
git checkout master
git merge feature
合并时可能遇到冲突，需要手动解决后 git add . 再提交。
三、Rebase：线性地重演分支提交
1. 核心概念
Rebase：将另一个分支的提交“摘下来”，依次应用到当前分支的最新提交后面，历史呈现单条线性结构
，而不会生成额外的合并提交。
适用于：
在私有分支上保持整洁、线性的提交历史；
需要对提交做交互式编辑/合并/修改等操作（rebase -i）。
2. 常用场景
私人分支或未推送的分支：想在提交正式合并到公共仓库前，先“打磨”提交，去除无用的日志或合
并小提交。
线性历史需求：有些团队/项目希望提交历史无多余分叉，更易于追溯。
3. 特点与优缺点
优点：
历史看上去整洁：不会产生 merge commit，查看变更也更方便。
可进行交互式编辑：Rebase 可以合并多个提交、修改提交信息等。
缺点：
重写提交哈希：之前的提交会“被替换”成新的提交哈希，可能破坏其他人的引用或打 Tag。
在公共分支上执行 Rebase 会导致冲突，给其他合作人带来混乱。
4. 典型命令
# 在当前分支上，把 feature 分支的提交重新应用
git checkout master
git rebase feature
# 交互式 rebase
git rebase -i feature
四、三者的详细对比
1. 对比表
2. 共同点
都能把一个分支的修改带到另一个分支上，解决分支协作需求。
都可能在操作时发生冲突，需要开发者手动解决。
3. 不同点与适用场合
Cherry-pick：只挑选少量有用提交时最适合；若要整体合并分支，Cherry-pick 的效率和可维护性就低了。
Merge：团队协作最常见操作，简单、清晰，历史记录保留最完整，几乎不会干扰他人工作。
Rebase：适合你在个人或短期分支上想保持提交历史整洁，并且不会大规模影响他人；一旦推送到公共
仓库，需要非常谨慎。
五、工作流建议
默认使用 Merge：大多数团队合并特性分支时，会选用 merge，便于追溯和减少冲突。
私人分支 Rebase 整理：在将个人分支提交合并到主分支之前，可本地 rebase -i 一下，精简多余或临时
调试的提交，使最终 PR 更整洁。
局部提交用 Cherry-pick：只需移植某个或少数修复/提交时，可用 Cherry-pick，避免合并整个分支。
注意日后可能产生重复提交。
公共仓库历史尽量勿重写：如果你的分支已被他人拉取或 fork，rebase 或 cherry-pick 需格外谨慎
，以免给团队造成合并冲突与历史混乱。
六、Demo
1. Cherry-pick
dev 分支上有一个修复，哈希为 abc123，需要紧急上线到 master：
git checkout master
git cherry-pick abc123
git push origin master
2. Merge
git checkout dev
git merge feature/login
git push origin dev
3. Rebase
git checkout feature/cart
git rebase dev
# 解决冲突后，继续
git rebase –continue
git push origin feature/cart –force-with-lease
现在 feature/cart 的提交历史已经是基于 dev 的最新进度线性展开，无额外的合并提交。
七、总结
Cherry-pick、Merge、Rebase 都是将分支的改动带到另一分支的方法，区别在于“迁移范围”、“历史
显示方式”以及“对后续工作的影响”。
选择策略主要看目标：
若你只想复制几个提交且不干扰其他内容，Cherry-pick 是好帮手；
若要合并完整分支并保留多人协作痕迹，Merge 更简单可靠；
若追求最简洁线性历史或需要交互式编辑提交，Rebase 是首选，但需关注团队协作中的冲突与历史重
写问题。
团队协作开发要形成统一规范：
哪些分支只能使用 merge；
哪些分支可以 rebase；
何时可以 cherry-pick；
是否允许重写公共历史等。
熟练掌握这三种操作，并根据项目需要灵活选用，才能最大化提升协作效率，保持提交历史清晰可控。
原文链接：https://blog.csdn.net/guoqiankunmiss/article/details/147111141