Question

我在MASTER分支机构中提交了

1.commit 4930da17d8dd23d650ed38435d8b421816a0c451
  Date:   Sat Dec 5 14:34:18 2015 +0530

2.commit e1ebbbb599ee20ebec3ca92c26266d9fd16e7ccc
  Date:   Sat Dec 5 13:22:20 2015 +0530

3.commit e1721686be4be1eaf1618e199c70477c1383068f
  Merge: b1fdca0 51c7c21
  Date:   Sat Dec 5 12:11:50 2015 +0530

4.commit b4ab3c164a3a8d93e0a71a94b5c561cb5e20ebf6
  Date:   Sat Dec 5 12:09:56 2015 +0530

5.commit 167b1d10258381f09663ce61fa88ce3bbcd404c4
  Merge: 88f01ad 5ed302b
  Date:   Sat Dec 5 12:09:21 2015 +0530

6.commit c61bcadac673e1c83f4c14b66d56e23b12fa3198
  Date:   Sat Dec 5 12:07:58 2015 +0530

我有另一个名为TEST_MASTER的分支

现在我想从第3次提交合并到第6次提交，从分支MASTER合并到TEST_MASTER。装置

3.commit e1721686be4be1eaf1618e199c70477c1383068f
  Merge: b1fdca0 51c7c21
  Date:   Sat Dec 5 12:11:50 2015 +0530

4.commit b4ab3c164a3a8d93e0a71a94b5c561cb5e20ebf6
  Date:   Sat Dec 5 12:09:56 2015 +0530

5.commit 167b1d10258381f09663ce61fa88ce3bbcd404c4
  Merge: 88f01ad 5ed302b
  Date:   Sat Dec 5 12:09:21 2015 +0530

6.commit c61bcadac673e1c83f4c14b66d56e23b12fa3198
  Date:   Sat Dec 5 12:07:58 2015 +0530

Cherry-pick我试过，它正在运作。

在我的情况下，我有近100次提交，还有其他方法可以像

那样进行合并

from <commit-id> to to <commit-id>

Answer 1

正如我在“How to cherry pick a range of commits and merge into another branch”中所解释的那样，您可以使用git cherry-pick来合并一系列提交，而不仅仅是提交提交。

如果您想选择范围B到D（包括），那将是git cherry-pick B^..D

这允许您合并“从<commit-id>到<commit-id>”

OP报告范围还原失败，并显示：

Commit xxx is a merge but no -m option was given. fatal: cherry-pick failed.

当尝试选择非合并提交时：

git cherry-pick -m 1 <non-merge-commit>^..<sha1> 
  error: Mainline was specified but commit <xxx> is not a merge.  
  fatal: cherry-pick failed

最后一条消息不适用于Git 2.21（2019年第一季度）：

commit 1c32013见commit 4d67b4e，commit 37897bf，commit c812bd4，Sergey Organov (sorganov)（2018年12月14日）。{
^{（由Junio C Hamano -- gitster --合并于commit 77fbd96，2019年1月18日）}

  选择非合并提交时，
“git cherry-pick -m1”被禁止，即使此类提交的父级号为1。

这样做是为了避免在“cherry-pick”选择单个提交时出错，但对于可以选择一系列提交的“cherry-pick”不再有用。

现在，在选择任何提交时，允许“-m$num”选项，只要$num命名提交的现有父级即可。

从技术上讲，这是一个向后不兼容的变化;希望没有人依赖错误检查行为。

您可以在this thread中看到导致允许“cherry-pick -m 1”进行非合并提交的讨论：

来自Git的主要维护者Junio C. Hamano：

当挑选多次提交时，不可能在同一命令行上同时进行合并和非合并提交。
    未指定“-m 1”会导致拒绝处理合并提交，而在非合并提交时指定“-m 1”会失败。


即使在选择单个父提交时也允许“-m1”，因为为这样的提交定义了第一个父级，这是有道理的，特别是在范围上运行一个樱桃选择时，完全适用于上述原因。
  当樱桃选择一次提交时，它略微减少，但不是很大。

我认为要求“-m $n”不存在的原始推理，特别是因为cherry-pick最初仅用于重放一次提交，是因为它会导致有人提出该命令的行为就像{始终给出{1}}（并且当尝试相对于其第二个父项挑选合并时，让-m1覆盖它），这反过来鼓励'first-parent is special'世界观来自工具方面。

IOW，“特别对待第一家连锁店的世界观是正确的，因为Git有很多功能可以方便地使用这种世界观”是我们想要避免的。   相反：“这样的工作流程受益于   特别对待第一父链，所以让我们添加这样的功能“是我们想做的。”   当然，当时樱桃挑选允许合并和单亲提交的混合，这将使得需要做这样的补丁确实感觉更大，不存在。

现在，至少在我看来，世界几乎都认为第一父世界观通常非常方便且值得工具支持，因此下一个合乎逻辑的步骤可能是设置-m2默认为1（并允许命令行显式“opts->mainline”覆盖它。）   但这应该发生在这个补丁登陆之后 - 我认为这在逻辑上是一个单独的步骤。

和

在7e2bfd3f（“-m $n：允许樱桃采摘多次提交”，2010-06-02）首次出现时，提供范围以进行挑选的功能出现了很长时间在v1.7.2-rc0中。

（如I reported here）

允许选择合并提交的功能来自7791ecbc（“revert / revert：同时处理合并提交”，2007-10-23），首次出现在v1.5.4-RC0。

在原始上下文中选择一个提交，通过盲目地将“cherry-pick”传递给非合并提交来避免错误是完全合理的。
  可以公平地说，当我们7e2bfd3f时，我们没有重新考虑如何处理“-m 1”，但是说完全禁止它是没有道理的，这是完全不公平的历史修正主义。第一名。

对代码本身的更改看起来很明智，但单独应用此修补程序将破坏必须更新其期望的现有测试，并且此新行为必须受到新测试（或两个）的保护，以便我们不会意外停止接受“-m 1”表示单亲提交。

从提交合并到提交

1 个答案: