如何选择性合并master分支部分提交到版本分支并规避问题？

场景回顾 #

现有两个分支：

• master：提交序列为 a → b → c → d → e
• maintenance-8.x.x：提交序列为 a → x → y → z

需创建version-8.1分支，包含maintenance-8.x.x的所有提交（x,y,z），以及master的部分提交（c,e，排除b,d）；后续还要将maintenance-8.x.x的变更合并回master。

解决方案：用交互式rebase --onto实现选择性移植，避免重复冲突与提交 #

步骤1：创建基础分支 #

先从maintenance-8.x.x切出version-8.1分支作为基础：

git checkout maintenance-8.x.x
git checkout -b version-8.1

步骤2：选择性移植master的目标提交 #

使用git rebase --onto结合交互式模式，将master中b之后的c、e提交移植到version-8.1上，同时跳过d：

git rebase --onto version-8.1 b master --interactive

执行命令后会打开交互式rebase编辑界面，找到对应d提交的行，将开头的pick改为drop（或直接删除该行），保存退出即可。

关键优势：

• 仅需解决一次冲突：rebase过程中Git会按顺序应用提交，相同冲突只会出现一次，解决后后续提交会自动复用冲突解决方案。
• 提交溯源清晰：移植后的提交保留原始变更内容，Git会记录其与原master提交的关联，后续合并回master时，Git能识别c、e已存在于master，不会标记为重复变更。

步骤3：后续将maintenance-8.x.x合并回master #

待version-8.1验证完成后，直接将maintenance-8.x.x合并到master即可：

git checkout master
git merge maintenance-8.x.x

由于maintenance-8.x.x的提交（x,y,z）基于共同祖先a，且master已包含c,e，Git会自动合并x,y,z的变更，不会出现重复提交冲突。

备选方案：用cherry-pick结合提交标记 #

如果不想使用rebase，也可以用cherry-pick并添加原始提交标记：

git checkout version-8.1
git cherry-pick -x c e

-x参数会在提交信息末尾添加(cherry picked from commit <原提交ID>)，后续合并回master时，Git能通过该标记识别变更已存在，减少重复冲突概率。但此方法仍可能需要多次解决相同冲突，推荐优先使用rebase方案。

内容的提问来源于stack exchange，提问作者Ray Morris