【问题标题】：git merge / cherry-pick into master after specific commit特定提交后 git merge / cherry-pick 到 master
【发布时间】：2018-04-16 11:59:12
【问题描述】：

我正在努力将分支“修补程序”合并到特定“位置”的“主”或在主分支不断更改时提交

“修补程序”分支当然是修补程序，需要从 master 跟踪以供以后使用。

你如何提供这个？

例子

A - B - C - D / master
    |
     \ 
      \_ hotfix containing commits E - F - G

“master”分支应该变成

A - B - E - F - G - C - D / master

有没有机会通过避免合并冲突来实现这一点？

PS：目标是不要有另一个分支，例如“修补程序/修补程序-123”。

【问题讨论】：

使用git rebase可以得到结果A-B-C-D-E'-F'-G'。但是，如果提交D 和G 之间“某处”存在任何冲突，则需要解决它们。重新排序（将E-F-G 放在C-D 之前）不能解决问题。
见What are the practical consequences of rewriting GIT history?
@JDB 著名并且已经意识到

标签： git merge

【解决方案1】：

编辑：更新以匹配下面 cmets 中给出的附加信息编辑 2：添加标记建议

目标：将修补程序合并到版本 1.0

首先，让我们重新表述一下你的原始图片。

A---B---C---D // master
     \
      E---F---G // hotfix

假设这就是历史当前的样子

      C---D // master (2.0)
     /
A---B  // current version 1.0
     \
      E---F---G // hotfix

我建议创建一个分支来跟踪版本 1

git checkout -b release/v1 <B's commit SHA>

并创建一个标签来标记实际发货的物品

git tag v1.0.0

然后将修补程序合并到这个新分支中

git merge hotfix

并创建一个标签来标记新版本并将其发布到需要的地方

git tag v1.0.1

您的历史现在将如下所示

      C---D // master (2.0)
     /
A---B  // tag v1.0.0
     \
      E---F---G  // branch release/v1 and tag v1.0.1

最后，听起来您不需要在 2.0 版中更改修补程序，但如果您这样做：

git checkout master
git merge hotfix

原答案

不可能将修补程序分支“合并”到 master 并让历史看起来像你想要的那样。但是，如果您愿意重写 master 分支，这是可能的。 警告：这将对在主分支和should be avoided 工作的其他人造成重大痛苦。

给定

A---B---C---D // master
     \
      E---F---G // hotfix

您可以通过

获得所需的历史记录

git checkout master
git rebase hotfix/foo

这将导致

A---B---E---F---G---C'---D' // master
     \
      C---D // original master

【讨论】：