从提交合并到提交 [英] merge from commit to commit

问题描述

我的MASTER分支中有一个提交

I have a commits in my branch 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的分支

I have another branch called TEST_MASTER

现在，我想将3次提交合并到6次提交，从分支MASTER合并到TEST_MASTER.意思

Now I want to merge from 3rd commit to 6th commit, from the branch MASTER to TEST_MASTER. Means

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 I tried, It is working.

在我的情况下，我有近100次提交，是否还有其他类似的合并方式

In my case I have nearly 100 commits, Is there any other way to do merge like

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

推荐答案

正如我在"中所解释的那样并合并到另一个分支中，您可以使用git cherry-pick合并一系列的提交，而不仅仅是通过提交进行提交.

As I explained in "How to cherry pick a range of commits and merge into another branch", you can use git cherry-pick to merge a range of commits, not just commit by commit.

如果您要选择范围B到D(含)，则为git cherry-pick B^..D

这确实允许您合并从<commit-id>到<commit-id>"

That does allow you to merge "from <commit-id> to <commit-id>"

OP报告范围还原失败，原因:

The OP reports that a range revert fails with:

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

并且在尝试选择非合并提交时:

And when trying to chose a non-merge commit:

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年第一季度)将不再提供最后一条消息:

That last message won't be there with Git 2.21 (Q1 2019):

请参见提交1c32013 ，提交37897bf ，提交c812bd4 (2018年12月14日)，通过 Sergey Organov(sorganov).
^{(由 Junio C Hamano-gitster-在}

See commit 1c32013, commit 4d67b4e, commit 37897bf, commit c812bd4 (14 Dec 2018) by Sergey Organov (sorganov).
^{(Merged by Junio C Hamano -- gitster -- in commit 77fbd96, 18 Jan 2019)}

选择非合并提交时，即使在 父级编号为1的情况下，也禁止使用

"git cherry-pick -m1".

"git cherry-pick -m1" was forbidden when picking a non-merge commit, even though there is parent number 1 for such a commit.

这样做是为了避免在"cherry-pick"只选择一次提交时出现错误，但是对于可以选择一系列提交的"cherry-pick"不再有用.

This was done to avoid mistakes back when "cherry-pick" was about picking a single commit, but is no longer useful with "cherry-pick" that can pick a range of commits.

现在，选择任何提交时允许使用"-m$num"选项，只要$num命名该提交的现有父项即可.

Now the "-m$num" option is allowed when picking any commit, as long as $num names an existing parent of the commit.

从技术上讲，这是一个向后不兼容的更改；希望没有人会依赖错误检查行为.

Technically this is a backward incompatible change; hopefully nobody is relying on the error-checking behaviour.

---

您可以在来自Git主要维护者Junio C. Hamano:

From Junio C. Hamano, main maintainer of Git:

当樱桃采摘多次提交，它不可能对同一命令行两者merge-和非合并的提交.结果 不指定'-m 1'会导致Cherry-pick拒绝处理合并提交，而指定'-m 1'会在非合并提交时失败.

When cherry-picking multiple commits, it's impossible to have both merge- and non-merge commits on the same command-line.
Not specifying '-m 1' results in cherry-pick refusing to handle merge commits, while specifying '-m 1' fails on non-merge commits.

正是由于上述原因，

即使在选择单个父提交时也允许"-m1"是有道理的，因为为该提交定义了第一个父提交，尤其是在范围上运行Cherry-pick时.
挑选一次提交时，它要少一些，但不是很大.

Allowing "-m1" even when picking a single parent commit, because the 1-st parent is defined for such a commit, makes sense, especially when running a cherry-pick on a range, exactly for the above reason.
It is slightly less so when cherry-picking a single commit, but not by a large margin.

我认为不存在要求"-m $n"的原始原因，尤其是因为cherry-pick最初仅用于重播单个提交，是因为这会导致有人建议该命令的行为就像-m1总是被赋予(并且当尝试相对于其第二个父节点选择合并时，给出-m2来覆盖它)，这反过来又从工具的角度鼓励了第一对父辈是特殊的"世界观.

I think the original reasoning for requiring "-m $n" not present, especially because cherry-pick was originally for replaying only a single commit, was because it would lead somebody to propose that the command should behave as if -m1 is always given (and when trying to cherry-pick a merge relative to its second parent, give -m2 to override it), which in turn encourage the 'first-parent is special' world-view from the tool-side.

IOW，我们要避免的事情是，特别对待第一对父母的世界观是正确的，因为Git具有许多可以方便地使用该世界观的功能".
而是:这样的工作流程将从中受益 我们想做的是，特别对待第一对父母链，所以让我们添加功能来做到这一点.
当然，那时候不存在允许选择合并和单亲提交的混合的樱桃选择"，这本来会使需要做类似此补丁的事情变得不那么需要了.

IOW, "The worldview to treat the first-parent chain specially is correct, because Git has many features to work with that worldview conveniently" was something we wanted to avoid.
Rather: "Such and such workflows benefit from treating the first-parent chain specially, so let's add features to do so" was we wanted to do.
And of course, back then cherry-pick that allows mixture of merges and single-parent commits to be picked, which would have made the need to do something like this patch does felt greater, did not exist.

现在，至少在我看来，这个世界似乎已经完全接受，初次祖父母的世界观通常非常方便并且值得该工具支持，因此下一个合理的步骤可能是将opts->mainline设置为1默认情况下(并允许命令行中的显式"-m $n"覆盖它).
但这应该在此补丁着陆后发生-我认为这在逻辑上是一个单独的步骤.

Now, it appears, at least to me, that the world pretty much accepted that the first-parent worldview is often very convenient and worth supporting by the tool, so the next logical step might be to set opts->mainline to 1 by default (and allow an explicit "-m $n" from the command line to override it).
But that should happen after this patch lands---it is logically a separate step, I would think.

并且:

在 7e2bfd3f revert:允许进行多次提交的樱桃采摘"，2010-06-02)首次出现在v1.7.2-rc0中.

The feature to give a range to cherry-pick came much much later in 7e2bfd3f ("revert: allow cherry-picking more than one commit", 2010-06-02) that first appeared in v1.7.2-rc0.

(如我在此处报告)

允许选择合并提交的功能来自 7791ecbc ("/cherry-pick:也可以处理合并提交"，2007-10-23)，最早出现在v1.5.4-rc0中.

The feature to allow picking a merge commit came in 7791ecbc ("revert/cherry-pick: work on merge commits as well", 2007-10-23), first appeared in v1.5.4-rc0.

在最初的上下文中选择单个提交，将盲目地将'-m 1'传递给非合并提交避免错误是非常有意义的.
可以公平地说，当我们-m 1' > 7e2bfd3f ，但是说一开始禁用它毫无意义，这完全是不公平的历史修正主义.

In the original context to pick a single commit, it made perfect sense to avoid mistakes by blindly passing '-m 1' to non-merge commit.
It may be fair to say that we failed to reconsider what to do with '-m 1' when we did 7e2bfd3f, but it is utterly an unfair history revisionism to say that it made little sense to disable it in the first place.

对代码本身所做的更改看起来很明智，但仅应用此补丁程序将破坏必须更新其期望的现有测试，并且此新行为必须受到一个(或两个)新测试的保护，以便我们不会意外停止接受"-m 1"进行单亲提交.

The change to the code itself looks sane, but applying this patch alone will break existing tests whose expectations must be updated, and this new behaviour must be protected by a new test (or two) so that we won't accidentally stop accepting "-m 1" for a single-parent commit.

这篇关于从提交合并到提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！