合并/挑选从分支 A 到分支 B 的一系列提交答案

【问题标题】：Merging/Cherry-Picking a range of Commits from Branch A to Branch B合并/挑选从分支 A 到分支 B 的一系列提交
【发布时间】：2020-12-11 15:02:06
【问题描述】：

操作系统：Windows 10

Git 客户端：Git Bash（版本：2.28.0.windows.1）

...--A--B--C--D---E--I--M--N--O--P   <-- Branch-A
  \  \       /
   \  F--G--H
    \
     J--K--L   <-- Branch-B (HEAD)

问题陈述：

What I want to do is, Merge/Cherry-Pick commits (I .. P) to the branch (Branch-B)

我尝试过的：

我已经使用以下命令尝试了 git cherry-pick：

git cherry-pick I..P

但不是从提交 I 合并到 P。cherry-pick 正在从 I 到 A 执行（即在历史上倒退）。

任何解决方案？也欢迎樱桃挑选以外的解决方案。

【问题讨论】：

你能描述一下你是如何看到应用的提交是“I to A”的吗？

标签： git gitlab git-merge git-bash cherry-pick

【解决方案1】：

更新 - 我一直在看这个，我看不出你指定的命令会如何做你所说的。如果您以Branch-B 开头，请签出并说

git cherry-pick I..P

那么你应该得到从M 到P 的提交副本添加到Branch-B。由于您还想获得I，因此您应该改用E..P，但是cherry-pick 在历史记录中“向后”工作的想法没有意义，或者与文档相匹配，或与我的测试相匹配。

我也稍微调整了我的答案。我仍然更喜欢使用rebase 来表示提交范围，但我最初说这是“最简单”的方式，客观上这并不准确，因为它需要对分支进行额外的操作。

我复制一系列提交的更改（只要该范围不包括合并）的方式是使用 git rebase 使用 --onto 选项。可能看起来像这样：

git rebase --onto Branch-B E P

请注意，您指定E，而不是I，作为“上游”参数。这是因为 rebase 将此参数视为负引用 - 从 E （包括 E 本身）可以访问的所有内容都不会被复制。

另外请注意，我指定P 作为最后一个参数，而不是branch-A。那是因为如果您在签出分支的情况下进行变基，分支会随着重写的提交而移动，这听起来不像您想要的那样。结果是您现在处于分离的 HEAD 状态，并且重写的提交当前不在任何分支上。

...--A--B--C--D---E--I--M--N--O--P   <-- Branch-A
  \  \       /
   \  F--G--H
    \
     J--K--L   <-- Branch-B 
            \
             I'--M'--N'--O'--P' <-- (HEAD)

现在可以将这些提交整合到 Branch-B 中

git branch -f Branch-B
git chekcout Branch-B

或

git checkout branch
git merge -

得到

...--A--B--C--D---E--I--M--N--O--P   <-- Branch-A
  \  \       /
   \  F--G--H
    \
     J--K--L--I'--M'--N'--O'--P' <-- Branch-B (HEAD)

【讨论】：

执行命令后，cherry-pick 会合并提交 E 中所做的更改。发现冲突并要求我解决。在解决并提交更改后，我执行 git cherry-pick --continue。它要求我分别编辑合并提交 E、D... 的评论。我知道那不是它应该表现的方式。我将尝试使用 git rebase --onto 并在此处分享更新。 @马克

【解决方案2】：

这没有任何意义。如果您希望看到应用在 branchB 上的第一个修订版是 I，您需要像 rhis 一样尝试：

git cherry-pick E..P

【讨论】：